[Cryptography] secure authentication ... as opposed to passwords

[Jerry Leichter]

> Every study I have ever seen says that typical users do not understand
> a model where one part of the screen is semantically different from
> another.  If it looks like a lock they'll assume it's secure (whatever
> "secure" means this week.)  If it looks like a password box, they'll
> type a password into it....
They have, of course, learned the lessons we've taught them well.  Every website wants to have its own login screen, configured the way it likes.  There is no expectation that any one can legitimately have other than "if it wants a username and password I should hand them over".

But there's actually an opportunity here, if we were to choose to seize it.  Imagine that the major browser makers coordinated on the following steps:

1.  Define a standard mechanism by which servers could ask for authentication information.  How and what form would be delivered would be specified in the request.  To ease adoption, a returned username and password would be available; but better methods would be included:  PAKE, some kind of challenge/response - not a long list of possibilities, but other *good* methods that we would hope to evolve to.

2.  Define a standard UI to be used for authentication requests.  The elements of the UI should be common across browsers and OS's, even if small details vary.  The UI must be independent of language - it mast be clear to someone familiar with the standard that they are looking at an authentication prompt even if they can't read the textual fields within it.  (They might not be able to determine what to type where if the language is different enough from anything they are familiar with, but they'll still know what, in broad terms, the prompt is about.)  There might need to be a small-screen version of the UI for phones and such.  Obviously, whatever the standard form is, it must be clearly distinct from anything that could be generated through HTML, Javascript, what have you.  There should be extensive testing with humans to make sure this really is distinctive.  An interesting and difficult challenge is figuring out how to do this for users who have visual impairments or other difficulties with standard UI's.  Designing this UI would make for a very interesting international contest.

3.  Get the new standards out there in browsers, and start to encourage web sites to use them.

4.  Browsers are already pretty good at spotting username/password prompts.  They have to be - and producers of web pages make it easy for them - to allow autofill of authentication information.  Use the same mechanisms, over time, to start warning users that the site they are on is using an obsolete and dangerous method for requesting sensitive information.  The warnings wouldn't start appearing until the new standard was broadly available, and would initially be restrained; but over time they become more strident and disruptive.  The precedent here is the warnings for self-signed certificates and Chrome's upcoming warnings about certificates that are not registered for certificate transparency.  (Note that one can argue whether those uses of such warnings are appropriate.  That's a separate issue from the fact that they've been used and, over time, have forced changes in behavior all over the Web.)

5.  An even broader step would be for Google (and other search providers - but this is the kind of thing Google has spoken about more than others) to start down-rating sites whose pages contained old-style authentication prompts.

6.  The goal is to make the new-style authentication so common that anything that doesn't use it will stand out as "wrong".  Only that way can we get away from the current user bias to enter usernames and passwords wherever they are asked for.

This is a way forward.  Whether we (collectively) choose to take it remains to be seen.
                                                        -- Jerry