[Cryptography] Order of username and password entry

[Lanlan Pan]

Natanael <natanael.l at gmail.com> 于2021年4月6日周二 上午7:22写道：

>
>
> 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.
>
> +1 ，
username + password  => cookie
2FA => PAKE, SMS verify，kerberos

> 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.
>
>> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210408/a81d4313/attachment.htm>