[Cryptography] Order of username and password entry

[Natanael]

Den mån 5 apr. 2021 23:50Michael Nelson via cryptography <
cryptography at metzdowd.com> skrev:

> Thought you guys might like a breather from bits and bytes. This is low
> tech security, but not entirely trivial.
>
> When you have to enter a username/password pair for a site, which do you
> do first?
>
> It's often the case for me that I paste both into the slots. When I did
> not have a fixed order, about once or twice a year I would paste the
> password into the username slot, whence it would be displayed in the clear.
> Usually you catch it then, but if not, it may be submitted to the site.
> Yikes!
>
> To avoid this, I now have a rule: always enter the username first, then
> the password. If you put the un into the pwd slot, the non-displaying will
> alert you.
>
> That's fine, but... Now the password is left in the copy/paste buffer, and
> can pop out when you are not expecting it. This is the lesser of the two
> evils. I have another rule: over-write the copy/paste buffer right after
> doing the password.
>
> Unix kill-ring yanking, and the supposed new Windows ability to save
> multiple items to the clipboard can mean that it's a bit cumbersome to
> clear out the buffers.
>
> Sigh. Any reflections?
>

Some thoughts;

Use a password manager with autofill (typing it in for you - do not use the
clipboard).

This way you don't even have to think about the order. Just unlock the
password manager and click to enter it.

If you need to enter it on a device which you do not have your password
manager DB on, then first enter username and then password, but I do it
that way mostly out of habit.

My suggestion if you're developing a website and control authentication
flow, and if you support 2FA;

Let the user enter their username, then demand 2FA verification (such as
WebAuthn), THEN ask for their password to confirm.

If you can use a PAKE for password entry then that's even better (as a PAKE
can hide the value of the entered password even from the server).

The ideal solution would be if browsers had an official API for binding 2FA
protocols to a PAKE protocol such that opening a prompt for password entry
would be always conditional on successful 2FA verification, and it should
signal when this protocol is used.

For example, when a site supports this combined protocol then the browser
could show the same kind of window it shows now for requesting that you
connect your security key & press a button, along with a password entry
field *in the same window* which is greyed out *until* you have
successfully verified with 2FA. It would clearly indicate that you first
has to press the button on your 2FA hardware token and then enter the
password into the PAKE based prompt.

(this could certainly also have integration with password managers)

This would give us an infinitely more phishing resistant authentication
method than anything else that is widely available today. The browser
controlled 2FA-then-pass flow with a 2FA hardware token (WebAuthn security
key) would teach users to not enter their passwords into insecure password
prompts, as the secure one would only open after a successful 2FA
verification, and since this flow never reveals the entered password to the
website.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210406/5d44b395/attachment.htm>