how does IM remember password securely?

How can msn messenger and others provide a way to remember password on disk and then send it to the server for authentication later? I searched for this topic and found a cou开发者_StackOverflow中文版ple solutions such as BCrypt. However it stores hashed value and i can't send it to the server to authenticate. Others suggested do not save but that is not very practical as i will have to ask user to enter password everytime my app starts which is very annoying

You didn't really say which system you're asking about. Mac OS X provides Keychain Services to handle this kind of secret storage. This question talks about the Windows equivalent.

How can msn messenger and others provide a way to remember password on disk and then send it to the server for authentication later?

They encrypt it, store it, then decrypt it on loading. The ones that are doing it properly will be using DPAPI to tie the keys to a Windows user's login. (This was previously done using ‘Protected Storage’.)

This still isn't “secure” as such, as if you can log in as that user there's nothing stopping you decrypting it. But at least it reduces the risk compared to the common approach of having the ‘secret’ key built into the app alone.

You encrypt the password using a "secret" two-way key hardcoded in your application.

And yes, your program could be reverse engineered (with various levels of difficulty, but never impossible) to discover the internal key. There's no way around that.

You can't.

To be precise, you can not write a program which directly writes a password to disk securely and then proceeds to extract that password without asking for any external input. If your program can do it, so can another. The best you can hope for along these lines is obfuscation.

There are clever things you could do in more restrictive scenarios (smartcards? TPM? existence of a centralized "keychain"?) which you probably can not assume.

My opinion: it isn't a big deal. There should absolutely be an option to not save passwords for public machines, but otherwise you might as well just store them in plaintext. Maybe you obfuscate it in some trivial way so that an attacker at least needs to know what they're doing, but there's no point in doing a lot of work for it.

In short, it doesn't. Depending on the software, it may encrypt the password on disk. I think firefox does something like this with saved passwords. However, this only obfuscates the password. Since the program must also store the encryption key on the disk, then it can be located and used to decrypt the password.

There are two possible solutions to this problem:

• The first is to simply ask the user to enter a password. Keychain type programs usually ask the user for a password before releasing the stored passwords. Thus, the password from the user can be used to encrypt the passwords file. The benefit of this system is a single password can be used to agregate all other passwords in the system (as opposed to having the user remember each one).

• The second is to use a TPM security chip found in most modern business computers (especially laptops). This is a hardware device that theoretically allows you to store encryption keys securely. In this way, you can store the encryption key securely. However, you must depend on the hardware device as well as an entire software infrastructure ot support it (you can't just use it isolation I don't believe).

Your choice of how to attack this problem depends on what you're trying to do. If you're writing a messenger client, then you're probably just fine saving the password using some type of simple encryption with an encryption key stored elsewhere. Depending on what platform you're using there should be libraries for this. If you're developing some type of data vault for HBI data, you'll want to find a use to utilize the TPM chip. If your platform has some type of keyring application, you'd probably want to use that if possible.

Usually passwords stored locally are encrypted, to it makes it harder to hack... however since the key to decrypt it is in the same machine (inside the IM) this encryption is never bullet proof.

They either save it unencrypted or with symmetric encryption, or they save it hashed and send it to the server the same way, not caring what the actual password is.

edit: The comments on this answer are correct, of course. Storing and sending the hash is surely not how it's done. Thanks for the correction.

just hash it the same way in your client app as you do on the server, you can eliminate the need to ever send the actual password that way.

obviously you'll have to hash your hash again when sending, otherwise the hash becomes tha password, but you can do the same on the server. Use some random token inside the authentication message.

Additions It's really not as hard to grok as the comments make it seem:

If you take the original password (plaintext) concatenate it with something like a MAC address, or email address, or username, or whatever you can reproduce on the server, you are salting the password and storing a relatively secure hash.

Upon authentication you do not just send this hash because that would defeat the purpose of the hashing process entirely, you randomly generate a nonce and concatenate that with the first hash before hashing again. then on the server, you get the nonce and the new hash, which you use to validate your server side hash, hence validating the originally entered plaintext password, without ever storing or transfering it.