[Bug] Password manager exposes the password length and decrypts without a private key!

Brass Contributor

This is a security issue that is out in the wild, though I do not think it is that so severe that it poses a risk to mention it here.

 

The page edge://settings/passwords allows the person in front of the computer to reveal passwords after they convince the browser about their ownership by entering their account's password, or their PIN on that device. That's cool!

 

The problem is, it also displays their actual lengths of the passwords without any proof of ownership! The problem here is two fold:

 

  1. How, even? How is it even able to do that in the first place? I would expect the passwords to be encrypted in such ways that even the browser itself cannot decipher the passwords, nor their lengths, without the private key, which should have been a derivative of the credential that the user should be entering.
  2. A premature hint! Exposing the length of the password is too much of a hint to tell someone who hasn't yet provided their proof of ownership. The browser is reluctant to expose the password as a whole; it asks for an authentication before doing that. Then, why is the browser even giving this piece of hint out? To convince the person in front of the computer that it really has the actual password? Aesthetics?

 

Just now I realized that the auto-fill somehow also enters my password in plain text to the websites, without asking any private key or sorts... I guess then being the person in front of an unlocked computer is enough to get the passwords deciphered (and entered via auto-fill). Then my question is in reverse: What is the point of keeping them censored on edge://settings/passwords at all, if we trust this person so much?

 

Windows in and of itself does not trust so easily: Fire up the "Credential Manager" (type that onto Start menu search). It displays the censored passwords with the dummy length of 8 or something. They are revealed only after authentication. I hope that, without authentication, it does not decipher the passwords nor give them away either. Why does a the browser give in?

 

Could you provide an option on edge://settings/passwords to let us choose to require authentication before auto-filling the passwords? Just like the one that pops up when you hit the "peek" button to reveal the passwords. I personally find the auto-fill as it is kind of insecure. I would rather enter my PIN every time I log in (with cookies, this doesn't happen so frequently anyway), than to have the equivalent of keeping my passwords in a passwords.txt that I hid deep in my Documents.

 

Sincerely,

Utkan

6 Replies

I totally agree,
Edge should make all of the passwords the same length when they are encrypted so their real length won't be known by anyone that doesn't have the correct credentials

@utkangezer 

 

Update:

If an attacker has unrestricted physical access to your computer, they can just convert the password fields to text fields or use DevTools to read them as plaintext.

#LockYourPCs

 

What about unmasking of passwords with the developer tools?

 

One of the most frequent reports we receive is password disclosure using the Inspect Element feature (see Issue 126398 for an example). People reason that “If I can see the password, it must be a bug.” However, this is just one of the physically-local attacks described in the previous section, and all of those points apply here as well.

 

The reason the password is masked is only to prevent disclosure via “shoulder-surfing” (i.e. the passive viewing of your screen by nearby persons), not because it is a secret unknown to the browser. The browser knows the password at many layers, including JavaScript, developer tools, process memory, and so on. When you are physically local to the computer, and only when you are physically local to the computer, there are, and always will be, tools for extracting the password from any of these places.

 

 

 

Why aren‘t physically-local attacks in Chrome’s threat model?

 

People sometimes report that they can compromise Chrome by installing a malicious DLL in a place where Chrome will load it, by hooking APIs (e.g. Issue 130284), or by otherwise altering the configuration of the PC.

We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your computer as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your computer, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

There are a few things you can do to mitigate risks from people who have physical control over your computer, in certain circumstances.

  • To stop people from reading your data in cases of device theft or loss, use full disk encryption (FDE). FDE is a standard feature of most operating systems, including Windows Vista and later, Mac OS X Lion and later, and some distributions of Linux. (Some older versions of Mac OS X had partial disk encryption: they could encrypt the user’s home folder, which contains the bulk of a user’s sensitive data.) Some FDE systems allow you to use multiple sources of key material, such as the combination of both a password and a key file on a USB token. When available, you should use multiple sources of key material to achieve the strongest defense. Chrome OS encrypts users’ home directories.
  • If you share your computer with other people, take advantage of your operating system’s ability to manage multiple login accounts, and use a distinct account for each person. For guests, Chrome OS has a built-in Guest account for this purpose.
  • Take advantage of your operating system’s screen lock feature.
  • You can reduce the amount of information (including credentials like cookies and passwords) that Chrome will store locally by using Chrome's Content Settings (chrome://settings/content) and turning off the form auto-fill and password storage features (chrome://settings/search#password).

There is almost nothing you can do to mitigate risks when using a public computer.

  • Assume everything you do on a public computer will become, well, public. You have no control over the operating system or other software on the machine, and there is no reason to trust the integrity of it.
  • If you must use such a computer, use Incognito mode and close all Incognito windows when you are done browsing to limit the amount of data you leave behind. Note that Incognito mode provides no protection if the system has already been compromised as described above.

 

 

Source

and

Source

To reiterate, Edge does not blindly trust the person sitting in front of the computer. It does ask the PIN from the user before showing the password in clear text.

 

However, while it doesn't fully trust the person sitting in front, it apparently trusts them "somewhat". It displays the true length of the password without PIN.

 

I don't see any reason for this "human-like" behavior, where the software (Microsoft Edge) doesn't fully trust or distrust the user, but trusts them "somewhat".

@HotCakeX  Actually that idea is great! Why did you cross it out?