Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How do current web browsers (or mobile mail clients and any software in general) save user passwords? All answers about storing passwords say we should store only hashes, not the password themselves. But I'm having a hard time searching the web trying to find the best techniques to store passwords when we know we will need them in plain text later on — without storing them in plain text, without using a weak encryption (known key) and without asking the user for a master password. Any ideas?

share|improve this question
    
This question is likely a better fit for the IT Security SE site. –  Bernard Mar 25 '12 at 18:07
    
@Bernard Thanks, I was not aware of the IT Security site... –  marcus Mar 26 '12 at 14:17

3 Answers 3

up vote 3 down vote accepted

locally it is either stored as plain text or encrypted.

when encrypted the en/decryption key can be fixed per browser (hardcoded in the executable), per machine (generated at install and stored in the install directory) or per user (generated at first time use of password manager and stored in the %appdata%)

or they can be combined: the user level key is encrypted with the machine level key so that when malware takes the file where the passwords are stored it is stored it is useless without the user level and machine level keys

Some browsers also allow you to use a "master" password which which is combined with the existing key to provide more security

when you use a (good) synchronization service the passwords are never stored in plain text on the server. Xmarks for example uses a separate key to your normal sync password to encrypt the passwords and never sends that key to the server (if you want to see the stored passwords on the site it is decrypted locally)

share|improve this answer
    
Thanks. From all the answers, it looks like there is no good "strong" solution, it's either plain text or some obfuscation (i.e. an encryption whose key can be obtained from the machine itself) –  marcus Mar 27 '12 at 2:05

The passwords are stored in plain text, unless a master password is used.

When people tell that you must store only hashes of passwords, they are talking about server-side storage, not client-side.

Server-side

When you have your own website when the users can register/logon with their passwords, you don't need (and must never) store the passwords themselves:

  • You don't need to store plain passwords, because you only have to verify that the password used during a logon matches the password given by the user while registering. You can do it with hashes, since different passwords would have different hashes¹.

  • You must not store plain passwords. What if your website is hacked? Moreover, many people reuse same passwords again and again, so you practically give to any hacker the ability to access your users Facebook account, mail account, etc.

Client-side

Browsers are different. They store the passwords on client machine, and must have an original password, not a hash.

This means that those passwords are stored in plain text in most cases.

  • Security-wise, it doesn't matter too much. Those passwords are stored in a directory which belongs to the user account. This means that it's up to the operating system (and to the user) to properly configure the permissions to the users files, and to restrict the access to the file which contains the passwords to the user himself.

  • User experience wise, this is the easiest thing to do. Another possibility is to encrypt those passwords by a master password, in which case the user would have to provide the master password every time he opens the browser. I'm pretty sure most users would never enjoy that.

    If the master password is stored somewhere, the same problem arises: if you store the master password in plain text, what's the point? If you encrypt it, you must have a master-master password.

Sync

Note that most browsers enable the users to sync their data across multiple machines. The sync uses a remote server to store the cookies, history, bookmarks and passwords. For example, Chrome uses Google servers to store this data.

In this case, the passwords are never stored in plain text on sync servers, otherwise, it would be a security issue. In Chrome, you have to choose the master password for sync (or use the one from your Google account). This master password will be used to encrypt the passwords (always), and other data like the history or the bookmarks (optional).


¹ For the sake of simplicity, you can imagine that the different passwords cannot have same hashes. In theory, this is wrong, since collisions may exist. In practice, if you use a strong hash algorithm, like SHA-256, you can neglect the risk of collision for a website even with millions of registered users. Things are different if you use an obsolete and depreciated hash algorithm, like MD5.

share|improve this answer
2  
You seem concerned about the way the master-password is stored but we don't really need (or want) to store it, do we ? From my understanding, we just need the master-password as a (part of the) key to decrypt saved passwords and to encrypt new passwords. As far as decryption is concerned, if the master-password is wrong, the decrypted specific password will (hopefully) be wrong as well. The real issue is for new passwords as we don't want to encrypt them with the wrong password but can't we check that the master-pass decrypt a default string properly (thus we need to store the encoded string). –  Josay Mar 25 '12 at 9:21
    
Agreed. Having a master password, puts you back in the same position you are server-side: check only. You can verify the password against a hash, then use the users input if it checks out. There is no need to store it permanently. This is also the mechanism used by some applications to update hash's when they become obsolete. Wait for the user to login, verify against the old hash, then rehash the input while it's still in memory in cleartext and store the new, more secure hash. –  Matthew Scharley Mar 25 '12 at 23:39
    
@Josay: we are concerned about the way the master password is stored if we don't want to ask the user to enter it every time he opens a browser. If the user has to enter it, is becomes very simple technically, since we store only its hash. –  MainMa Mar 26 '12 at 7:51
    
@MainMa Ok, I'm 100% with you then. –  Josay Mar 26 '12 at 10:48

These programs need the password in clear text (they need to submit it when requested). It is therefore stored as plain text. Many browser allow to encrypt all the stored passwords with a master password (asked only once).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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