<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Natanael <<a href="mailto:natanael.l@gmail.com">natanael.l@gmail.com</a>> 于2021年4月6日周二 上午7:22写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den mån 5 apr. 2021 23:50Michael Nelson via cryptography <<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:16px"><div dir="ltr">Thought you guys might like a breather from bits and bytes. This is low tech security, but not entirely trivial.</div><div dir="ltr"><br></div><div dir="ltr"><div>When you have to enter a username/password pair for a site, which do you do first?<br><br>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!<br><br>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.<br><br>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.<br><br>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.<br><br><div>Sigh. Any reflections?</div></div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Some thoughts;</div><div dir="auto"><br></div><div dir="auto">Use a password manager with autofill (typing it in for you - do not use the clipboard).</div><div dir="auto"><br></div><div dir="auto">This way you don't even have to think about the order. Just unlock the password manager and click to enter it. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">My suggestion if you're developing a website and control authentication flow, and if you support 2FA;</div><div dir="auto"><br></div><div dir="auto">Let the user enter their username, then demand 2FA verification (such as WebAuthn), THEN ask for their password to confirm.</div><div dir="auto"><br></div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div></div></blockquote><div>+1 ， <br></div><div>username + password  => cookie</div><div>2FA  => PAKE, SMS verify，kerberos<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">(this could certainly also have integration with password managers) </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></div></div></div>
_______________________________________________<br>
The cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com" target="_blank">cryptography@metzdowd.com</a><br>
<a href="https://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank">https://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
</blockquote></div></div>