Requirement of masking password

[maizuka]

The removing of 2.1.12 was taken at #570. At the same time, it has also removed a requirement for typed passwords to be masked.

| 2.1.12 | Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as built-in functionality. | ✓ | ✓ | ✓ | 521 | 5.1.1.2 |

Should we cover this as a new requirement, or is it no longer needed?

My suggestion:

Verify that passwords are not displayed as plain text in pages and password fields. Input fields should use type=password.

[maizuka]

I posted the same message to #570 today, but removed and re-posted here because it has already been closed.

[elarlang]

Arguments are provided in #570. No plan and point at the moment to cover it again with just a bit different wording.

It came from NIST, but it is optional there as well.

[maizuka]

NIST says:

In order to assist the claimant in successfully entering a memorized secret, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — until it is entered.

Although not stated clearly, the "option" needs masking before user's choice. Displaying as plain text extends the attack surface in public physical space.

[maizuka]

I mistake to close. Should I move to #570?

[elarlang]

Can you convince me and everyone else, why we need this requirement? What security problem it solves that it need to be presented in ASVS?

Also - "option to show password during filling logging form" and "do not display passwords as plain text" are really different things. One is feature for client to enter password and other is requirement for server side that do not send plain-text password back to client.

[maizuka]

The masking mitigates the risk of password leaks by people behind the user by looking at or taking a shot. It is sure that attackers may obtain by tracking move of the fingers.

And as I said, I think NIST has the assumption of masking, based on the word "option".

If it concludes that we allow plain-text fields, I will have no more argument.

One is feature for client to enter password and other is requirement for server side that do not send plain-text password back to client.

Yes, I agree. l should focus on password fields rather than pages.

[elarlang]

Ok, now I got it. Initially got confused from requirement 2.1.12 removal, as it not directly related to your proposal.

In total we should think about three "requirements" then (it's not proposal to put them to ASVS, just covering):

• when an user can enter a password, it must be "type=password" field. Maybe there are other techniques as well and use more abstract behavior "input field must not reveal password as plain-text by default" (goal: user can safely enter password to the application, without visually leaking to the screen)
  • removed 2.1.12 is separate from that, but can be merged into it (goal: to help user to enter password to the application, users may use more simple password when entering it back to the application is too complicated)
• application should never send user password back to client as plain-text (goal: to avoid password plain-text leakage to the client from the application)

example from last one - user is filling registration form, gets input validation error and all previously entered data is again prefilled to the form, including password field. password is presented in plain-text in returned HTML document, even if it's not visible as plain-text from user input.

Situation is debatable - without returning plain-text password to user, we can take away one potential leakage. At the same time, users are storing their passwords to browser (for browser autofill) and from the client it is readable anyway. But then it's the client choice.

[maizuka]

Thanks for clarifying and sorry for confusing.

For the last one, for example, I often see password is displayed in the confirmation page or the finished page with other field items just after submitting the HTML form. (form page -> confirmation page -> finished page)

If the returned password is not visible by masked or hidden field, it may be leaked from browser cache or user-saved HTML page. But I don't think of this as significant threat compared to leakage from the browser password storage.

[Sjord]

application should never send user password back to client as plain-text

In #1134 @elarlang argued that the application does not know the password when it is hashed, and 2.4.1 requires that the password is hashed, so 2.4.1 already enforces that the password cannot be send to the user. There is one exception: when the user logs in, it is possible for the login page or the destination page to reflect the password from the request. Should we re-add 2.5.3 to simply say to never reflect the password?

when an user can enter a password, it must be "type=password" field

I agree, and perhaps not only for the password for login, but also for configured API keys within the application. I think we should explicitly require <input type=password>.

[tghosth]

So @elarlang @Sjord @maizuka it seems like the action from this discussion is to add the obvious but important requirement:

Verify that passwords input fields use type=password to mask the entry.

Is this sufficient?

[elarlang]

If we going to add this, I think we need to combine it with deleted 2.1.12:

Verify that the user can choose to either temporarily view the entire masked password, or temporarily view the last typed character of the password on platforms that do not have this as built-in functionality.

Otherwise we send the message that any plain-text password entering or checking is not allowed. It is required for mobile-devices when typos are easy to happen and then users may choose too simple password to make it easy to enter.

[tghosth]

Ok so @elarlang we should not be requiring apps to allow unmasking the password but we should permit it, so:

Verify that passwords input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password on platforms that do not have this as built-in functionality.

What do you think?

[elarlang]

Text is ok. Now I need to think how to connect this requirement with deleted 2.1.12. The point for proposed one is a bit different, but maybe we can just use the new one as modification of 2.1.12?

[jmanico]

I like this direction, Josh.

[tghosth]

I think this is a decent modification/replacement for 2.1.12 which relates to the same key point whilst also being more sensible.

Opened #1710

[elarlang]

From https://github.com/OWASP/ASVS/pull/1710/commits/64982c18368c4f29811ab83033ab8e4f8cd78a03

"... on platforms that do not have this as built-in functionality"

do we actually need this part? What it gives extra?

[tghosth]

I take your point. It is a little redundant and would be hard to validate.