2

Some password managers can automatically fill passwords in user's browser. But for this auto-fill to be secure, they have to make sure they are putting password in the correct input field, plus, the information is not leaked to 3rd-party software. Here are some questions:

  1. How do these password managers correctly identify the password input field on a web page? It may happen that a web page contains multiple password input fields. How does the password manager know which one it should fill in? If it puts password in the wrong field, is it possible for the information to be leaked (by some JavaScript event handlers, for example) even if the form isn't submitted yet?

  2. Most of these password managers come in the form of browser addons. Does the browser have any security mechanism to prevent other addons to access the password information, before (when password information in the addon) and after (when password information on the page) it is filled in?

  3. If there is a local password vault, then most likely it's stored as a file on the user's local filesystem. Since the password manager can fill password in plaintext, the local system has enough information to recover the password, regardless of what is actually stored in the password vault. But then wouldn't other programs on the user's local system also be able to recover the password?

|improve this question

closed as too broad by Steffen Ullrich, Tom K., M'vy, ThoriumBR, Stephane Jul 10 '18 at 6:05

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I think you can't say "they're doing it like this or that". It depends on the software, how they solve problems. – trietend Jul 1 '18 at 19:16
  • All your questions have different answers depending on the specific password manager. The only generic answer we can give is to 3) obviously at some point the unencrypted password must be in the RAM of the password manager, and a process with admin rights can read RAM of other processes and could hence capture it. However note that password managers are not designed to be used in an already compromised system, so all your points are moot... – Bakuriu Jul 1 '18 at 20:49
  • @Bakuriu Do you mean there are multiple ways of mitigating these concerns? Would you please give 1 or 2 examples about how they do it in a secure way? As for Question 3, I think a program on the user's system may not even need to have admin rights to gather the output (the password in plaintext). Instead, it can simply gather the inputs (the information used to calculate the password) as the current user and calculate the password by itself. That seems to mean every program the user runs has the potential to calculate password. How can those password managers handle this? – Cyker Jul 2 '18 at 3:16
  • @Cyker Well, you can make it harder. For example I use passphrase+key file to decode my password db with KeePass. In this way a normal keylogger wouldn't be able to use the passphrase. It would either need to strace the syscalls the process makes or record the desktop and recognize the file dialog and which file was selected (I do not type the name, I only select it via mouse). The keyfile could be in an external harddrive that is mounte only for the 5 seconds needed to decrypt the db, in that case it would be extremely hard to get a hand on it. – Bakuriu Jul 2 '18 at 18:08
  • Question 2 is about browsers. You should really look at their docs and ask to the developers. Basically the answer to that question is: yes, no, kinda depending on which browser. Question 1 again is: yes, no, kinda. KeePass is an offline password manager so you select the input field. – Bakuriu Jul 2 '18 at 18:10
4

How do these password managers correctly identify the password input field on a web page?

Password fields contain input type="password" in the HTML for the input field. This tells the browser and any associated extensions that input to the field should be treated as sensitive. This is what tells the browser to warn you if you are sending it over an unencrypted connection, and also what causes the input to be replaced with dots. In fact, if you edit the source of the page to remove this, you will notice that the characters you type in are not hidden anymore. A browser extension will be able to access this information as well (it is usually exposed in the extension API), and it uses this to determine which fields are password fields.

Does the browser have any security mechanism to prevent other addons to access the password information, before and after it is filled in?

No. Any other extension with equivalent permissions will have the exact same access. They can see exactly what the password manager is writing to the input field, and will be able to see the password that is being sent. However, it will not be able to read the password database by itself, since one extension cannot read the local database of another extension.

But then wouldn't other programs on the user's local system also be able to recover the password?

Yes, usually. While a master password may be used to encrypt these passwords, a local process running under the same user could easily hijack the browser to read the master key next time it is input. This is because a password manager's purpose is simply to let you use unique passwords for each website so you do not risk reusing the same passwords everywhere. They may add useful features like automatic password generation or encryption with a master key so someone who steals your computer cannot log into your sites, but that is not their primary purpose.

A browser password manager is designed to protect from a few threats, specifically:

  • A malicious or compromised website which can see the password you provide. If you use the same password for that site as for many other sites, that website will be able to impersonate you. A password manager allows you to seamlessly generate and use secure and unique passwords for every website you register on. A browser-based password manager simply makes integration with your web browsing experience easier.

  • An attacker who gains offline access to your password manager database, such as a laptop thief. If the password manager uses a master encryption key, which most do, then the thief will not be able to find out what passwords you are using. If the attacker is a local process running on the same machine, all bets are off. Password managers do not and cannot protect from such a threat. Proper system hardening and prompt security updates will.

|improve this answer
  • What do you think if there are multiple <input type="password"> on the page? Some sites keep multiple passwords for different types of service. The password manager has no control over how the site owners write their page. How is it possible for it to guess which password should be filled into which input field? – Cyker Jul 7 '18 at 2:28
  • @Cyker It contains more than just the input type. It also has a unique ID. For example, from a mail service, <input name="_pass" id="rcmloginpwd" type="password"> – forest Jul 7 '18 at 3:17
  • Well then I guess probably the password manager can learn which password is for which field on which page when user fills it in for the first time, and hopefully the site owner doesn't change the field id/name afterwards. – Cyker Jul 7 '18 at 8:57
  • @Cyker If they changed the IDs, they would also break things like browser password autocomplete and saved passwords. I can't think of why anyone would do that. – forest Jul 8 '18 at 3:01
  • Now I think those password managers probably work in the same way as the browser password auto-complete. So yeah the site devs probably want to keep identifiers stable. – Cyker Jul 8 '18 at 3:09

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