Best practice to store passwords in an application

[ahmd]

Here's the situation. I write an application that allows a user to connect to a third party cloud-based storage to upload/download data files from my application. That third party service requires a user to specify their user name and password for every session that my application attempts to connect to it. Unfortunately such user name and password must be provided in an open text form (although via a secure HTTPS protocol).

I will implement an option in my software (via a check box) to allow a user to chose to store their user name and password.

The question I have is how do you store this sensitive information on a local system?

[Flector]

Best practice:

* you can't avoid browsers with password memory
* don't allow paste into the password entry box
* previous passwords are saved in an encrypted file

[laserlight]

I will implement an option in my software (via a check box) to allow a user to chose to store their user name and password.

The question I have is how do you store this sensitive information on a local system?

Encrypted. However, for this to be useful, the key must be stored separately such that if your database is compromised, the key would not also be compromised.

[ahmd]

Thank you. Any specifics on encryption?

[alanjhd08]

I was going to suggest looking at FileZilla, since it's open source and allows you to store password for FTP/SFTP login. However, when I checked I see it stores them as plain text in an XML file, so that's probably not a good idea...

The Chromium source code might be a good place to look for ideas though, Chrome stores passwords in an SQLLite encrypted database on Windows

[Lindley]

If you're caching client-side passwords (so that your program can log the user onto something else), you have little choice but to store the actual password (encrypted of course). If you are acting as a server and storing what password the user should use to log on to your program, however, there's a better option.

Put simply: don't store the password at all. Instead, store a one-way hash of the password. MD5 used to be popular but I think it may have been compromised. Anyway, the idea is that when a password is entered, you hash it and compare the hash to the stored hash. Due to the way one-way hashes work, it is impossible to predict what passwords might have the same hash as the actual password; and even if someone obtains your stored hash, they cannot predict what password might enable them to log in to your program using it.

[ahmd]

Yes, hash of a password is definitely the way to go if I was doing the actual user authentication (although I'd use SHA1 instead of MD5). You see the problem is that I have to send user name and password in a text form via an HTTPS connection for authentication and thus hashing it won't do me any good.

So the bottom line from that was said above is, I'll store the password encrypted in a (SQLite) database and the hash key to decrypt it will probably go into the system registry. Shall I make the decryption key specific for each machine? Or just hardcode it in the application?

[laserlight]

Chrome stores passwords in an SQLLite encrypted database on Windows

I haven't used Chrome's password manager, but the typical way these utilities work is that the user is required to enter a passphrase to unlock the list of stored passwords. That passphrase could be used to form the key to decrypt the storage of those passwords. ahmd does not have such a luxury since the aim is to avoid requiring the user to enter any credentials in the first place (though that might be the crux of the problem, and a potential security loophole in itself).

If you're caching client-side passwords (so that your program can log the user onto something else), you have little choice but to store the actual password (encrypted of course).

That's what ahmd is doing

Anyway, the idea is that when a password is entered, you hash it and compare the hash to the stored hash.

If you ever have reason to do this yourself, remember to use a user specific salt too.

Or just hardcode it in the application?

I think hard coding a key is a bad idea.

[alanjhd08]

I haven't used Chrome's password manager, but the typical way these utilities work is that the user is required to enter a passphrase to unlock the list of stored passwords.

The user doesn't need to enter a passphrase. If you ask it to store the password, it will provide it automatically when you are logging on to a site. Many other browsers have a similar functionality.
So, I think this is the same thing that ahmd wants to achieve.

[ahmd]

Thank you both again. I agree that storing a password is a bad idea and this option will clearly be off by default, but let's admit it, these days many users demand ease of use and that is what remembering a password is, and if such option is not implemented my product is risking to be branded "not user friendly." And unfortunately there's no way around being user friendly and secure at the same time, is there?

In any way, since in my case remembering the actual password in a text form is a must, there's no encryption that will guarantee a 100% protection against reverse engineering of a compromised system. Thus, doing it like was suggested before seems to be a viable solution: store the password encrypted in a database (SQLite for instance), the key for decryption for the password goes into the system registry. This key should be unique for each installation of the software.

[laserlight]

The user doesn't need to enter a passphrase. If you ask it to store the password, it will provide it automatically when you are logging on to a site.

Logically, that means that if encryption is used, the key is stored in a place where it can be accessed by an attacker who has access to the ciphertext, hence the security provided by the encryption is an illusion, although it is still better than just storing the passwords in the clear.

Many other browsers have a similar functionality.
So, I think this is the same thing that ahmd wants to achieve.

I note that Firefox allows for a master password. This would be a correct approach security-wise, but as ahmd noted it can be perceived as not user-friendly to require it.

[Paul McKenzie]

but let's admit it, these days many users demand ease of use and that is what remembering a password is, and if such option is not implemented my product is risking to be branded "not user friendly." And unfortunately there's no way around being user friendly and secure at the same time, is there?

Why not make this a configurable option? Whoever wants more security goes into "Preferences" or whatever you want to call it, and sets it up. Whoever doesn't want it gets the default settings.

Regards,

Paul McKenzie

[alanjhd08]

Hi,

I took a look at the way various browsers and utilities implement this, and the default methods for a lot of them are very insecure. For Firefox for example, any user with admin rights on the PC can simply copy/paste the logins for another user. Some others just store the passwords in plain text.

I see that under Windows, Chrome uses CryptProtectData to encrypt the password. That might be secure enough for what you are trying to do, especially if you add a master password for users that want extra security.

Alan

[TheGreatCthulhu]

Why not make this a configurable option? Whoever wants more security goes into "Preferences" or whatever you want to call it, and sets it up. Whoever doesn't want it gets the default settings.

That sounds reasonable. The best solution is usually the simplest one. (Well... That phrase has been misused and misinterpreted in various ways, but you know what I mean.)

[ahmd]

I took a look at the way various browsers and utilities implement this, and the default methods for a lot of them are very insecure. For Firefox for example, any user with admin rights on the PC can simply copy/paste the logins for another user. Some others just store the passwords in plain text.

Thank you for doing this. So can you post which browsers do it in an "insecure way". I'm sure people would like to know?

Also how did you test it all?

I see that under Windows, Chrome uses CryptProtectData to encrypt the password.

Great! Thanks. That might work for me and I don't have to invent my own encryption.

Why not make this a configurable option? Whoever wants more security goes into "Preferences" or whatever you want to call it, and sets it up. Whoever doesn't want it gets the default settings.

There's no need for the Preferences setting. There's simply a check box below the log in screen that says "Save user password" that is off by default. I'm thinking to implement a balloon pop-up with a mild warning in case a user puts this check on.