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?

  • This question is likely a better fit for the IT Security SE site.
    – Bernard
    Mar 25, 2012 at 18:07
  • @Bernard Thanks, I was not aware of the IT Security site...
    – marcus
    Mar 26, 2012 at 14:17
  • As of today (Chrome 60), Chrome has been storing clear text passwords since ... well, ever. There is heated discussion about how well these clear-text passwords need to be protected from user access. Enjoy a lot of valid arguments from both side here.
    – bers
    Aug 30, 2017 at 12:24

3 Answers 3


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 and never decrypted server side.

  • 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, 2012 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.


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.


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.


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.

  • 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).
    – SylvainD
    Mar 25, 2012 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. Mar 25, 2012 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. Mar 26, 2012 at 7:51
  • @MainMa Ok, I'm 100% with you then.
    – SylvainD
    Mar 26, 2012 at 10:48
  • 1
    It's worth noting that most browsers now use the OS's key-store where one exists. For Example, If I were to store my SO username and Password on my PC (firefox on Win 10) it would be stored in the key-store. This is encrypted, but unlocked when logging in. someone sitting at my PC logged in as me could access them, but if logged in as someone else, my passwords would not be attainable.
    – Baldrickk
    Feb 28, 2019 at 11:50

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).

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.