0
$\begingroup$

It's universally accepted that storing an unencrypted password for automated authentication is a very bad idea, for the saved password can be used by malware, etc.

There is a number of systems that store encrypted passwords for the purpose of automated authentication elsewhere. For example, one can configure git to automate authentication during git push. My question is: how do such system manage to authenticate securely?

Specifically, here are two possibilities:

1) The local system stores the encrypted password, and when needed, sends it to the remote system. The remote system accept the encrypted password for authentication.

However, in this case the encrypted password leads to exactly the same vulnerability as unencrypted password: malware can use the unencrypted password to authenticate itself. For example, if your password was "brown fox" and it was stored as a hash 14921776, and the remote system would accept 14921776 as a valid authentication certificate, then malware can just look up 14921776 in the encrypted password file in the local system and use it as is.

2) Suppose now that the remote system does not accept the encrypted password for authentication. In the above example "brown fox" needs to be communicated between local and remote system; the hash 14921776 won't do.

How does the local system would provide automated authentication in that case? All the local system knows that the hash of the password is 14921776, but it cannot unhash it into "brown fox", and therefore cannot send the valid password to the remote.

$\endgroup$

2 Answers 2

1
$\begingroup$

Actually, storing an unencrypted password can be OK in certain circumstances, depending on what the password is used for and the threat model you are trying to defend against.

In any case, if you are authenticating to a remote system, you probably should be using public-key cryptography instead of a password if you possibly can.

Some relevant readings:

$\endgroup$
0
$\begingroup$

In this case unfortunately there is no 100% "secure" solution against malware or another user which works on the same privileges level as intended user does. If you can read password they can too...

There are few possible things that could make this more secure.

First of course is passphrase like SSH does to private key management although it would need prompting it every time or once during some kind of cache session. Setting cached password for only some limited time and removing it automatically after that is one of solutions used too. Of course UNIX chmod 400, hiding files (leading .(dot)) are another helpful steps, storing password in encoded format is too.

You confused few things here too, hash is one way function so it is totally different thing to encryption.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.