9

In the html of client side. If we change the type="password" into type="text", the password is displayed as plain text in browser. Is there any security issue about this? If it is, what is the solution to this issue?

Example as follows:

type="password" enter image description here

type="text"

Daniel
  • 981
  • 3
  • 11
  • 15
  • https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#what-about-unmasking-of-passwords-with-the-developer-tools – Josh Lee May 17 '18 at 20:05

6 Answers6

5

There are two rather different security issues involved.

One of them is the one so often mentioned as a reason for using input type=password: to protect the user against prying eyes. This is seldom relevant, since passwords are normally typed (and should be typed) so that there is nobody else looking at your screen or your hands.

The other one is different treatment of input type=text and input type=password by browsers in their histories and in using previously entered data as defaults or as selectable options. This varies by browser, but quite often, input type=text causes an automatic prefill if data has previously been entered in a field with the same name. Using the autocomplete=off attribute usually prevents this in modern browsers. On the other hand, browsers may store username/password pairs to make frequent visits to a site more comfortable; this can be an essential usability improvement and an essential security threat. It is typically based on recognizing a pair of input type=text and input type=password.

You could leave the decision to the user by offering both options. Perhaps the least distract way to do that is to have an input type=password with a checkbox “Show password when typed”, JavaScript-driven of course, which when checked turns type=password to type=text.

There is no difference between input type=text and input type=password. in handling the data, once it has been read. In both cases, the data will be sent to the server as unencrypted, unless the entire form data is encrypted.

Jukka K. Korpela
  • 195,524
  • 37
  • 270
  • 390
  • 4
    `There is no difference between input type=text and input type=password` while I was working on this in electron I stumbled upon an edge case where ´ + e = é can only be handled by type=text. password fields would create e. – Philipp Mar 07 '18 at 15:07
4

Well, the issue is that the password is displayed in plaintext on the screen. This gives anyone shoulder-surfing the opportunity to see the password. It's typically hidden so people who just happen to stand around cannot see the password being typed in and one can type in a password even with not-so-trusted people nearby.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • That’s the common explanation, but if people can see your screen, what guarantees that they won’t see your fingers hitting or touching the keys? – Jukka K. Korpela Jun 10 '13 at 06:06
  • 1
    @Jukka Sure, but it is somewhat possible to cover the keyboard either with your hands or simply the upper body, while it's very infeasible to simultaneously also cover the screen. It's also a lot harder to pick out keys being pressed, especially by a fast ten-fingerer, than it is to just read the characters off the screen. – deceze Jun 10 '13 at 06:19
  • 1
    Prying key typing is not that hard, nowadays, as any mobile phone can record videos (from a convenient angle, the typed keys can be easily seen, even from a ten-finger fast typing, I did that watching a film in slow motion, just for curiosity, to know what the character's password would be - turned out it was random, the actor just typed in anything, then hit ENTER). – Cyberknight Feb 11 '19 at 18:09
2

2017 here and the question is pretty popular and I think very important.

Technically there is no difference in handling data, but password fields are the flag for different analytics plugins/dictionary extensions/autocomplete tools etc. to not analyze and track such fields. For example, when you type in text field hotjar tracks it's content and sends to their servers, but they skip sending when they see password or credit type number.

Are there any security issues when your users' passwords will be sent to third party companies?

Dmytro
  • 2,200
  • 3
  • 20
  • 32
1

There is no such security issue in having the password field as type text. It is done only to prevent people sitting beside you or "physically" spying on you to find out about your password.

Zero Fiber
  • 4,417
  • 2
  • 23
  • 34
1

Is there any security issue about this? If it is, what is the solution to this issue?

Yes, there is a security issue. Mostly of 2 types:

  1. Shoulder Surfing.
  2. Save Password on Browser or from history.

For Type 1, the user needs to be discrete and manage his environment better.

For Type 2, the user could walk away from his computer and another user could basically type out the username, the browser could prompt the user to autofill the password and you are through.

Now to close this security. Turn off the saving password at your browser end. The browser will not be able to save the password. So it's not exposed to other users if they change it from text to password.

Ideally, no autofill should be available for Security.

Abhijeet
  • 11
  • 1
-1

This is a serious security flaw from the user's standpoint

Consider this scenario:

Chrome or Safari save password/usernames and automatically fills them when you visit the designated website. What if you left your computer open in a public place? It would be so easy for a 3rd person to reveal your passwords.

Macbook's keychain app requires you to enter the computer password to reveal the internet passwords (safari passwords), right? But if somebody opens the the website from your computer and navigate to the login page, the password and username/email are there. If you have already signed in, then they just need to first log you out and re-open the login page. Then; all they have to do is to change the input type from password to text to reveal your password. That's it!

If this was not a security flaw, then why Macbook Keychain Access App requires you to enter computer's password to reveal the internet passwords? Are they basically not the same thing?

You must protect the password fields from changing their types via dev tool!

I created a simple javascript snippet to protect password inputs against changing their types using dev tool (i.e: chrome dev tool). See live demo and test it out:

- https://codepen.io/mcakir/pen/zpZXxe

Note: It is written using vanilla javascript so it doesn't depend on any library (i.e: jQuery)

Must Ckr
  • 310
  • 2
  • 5
  • 3
    Worth noting that loading that codepen, turning off JS and then changing the type bypasses this snippet. I'd imagine if someone is savvy enough to open dev tools to change the input type, then the thought of turning off JS isn't far off. – Darren Oct 11 '18 at 15:23
  • This answer just cloaks a more serious issue. Open the DevTools, right click in the element, click in "Store as global variable" then go to console and type "temp1.value". There you will see the password and by pass the script without disabling JS. – E. Zacarias Nov 28 '21 at 17:17