Comment by jimis | Hacker News Reader

Comment by jimis | Hacker News Reader

Parent Full thread

I would personally want to see the opposite: disable PLAIN or LOGIN or HTTP basic auth methods or plaintext HTML password-entry forms, and never ever send a password without a digest challenge-response method, even over TLS. Of course first the browsers would have to implement safer alternatives:

https://bugzilla.mozilla.org/show_bug.cgi?id=472823

https://bugs.chromium.org/p/chromium/issues/detail?id=116047...

Why? Because I can't trust all the 100s of companies and I login to, and their 1000s of employees. I don't want them to choose storing my password securely or not. I want them to be forced to do that. Like I choose "HTTPS everywhere", I want to choose "SCRAM-SHA-512 everywhere" or similar.

It's technology that has to provide me guarantees, and user education must only complement that.

Unfortunately we are far from that. Passwords are flying plaintext-inside-HTTPS, with various risks:

* database storing passwords insecurely

* passwords being stolen on the authenticating server (either because of server being pwned or from internal eyes).

* passwords flying fully in plaintext (no TLS) in the internal network behind the authenticating server.

* self-signed HTTPS MITM attacks on already self-signed-cert websites (especially dangerous on intranet websites inside companies; you'd be surprised how difficult it is to setup proper PKI and internal CAs).

Password based authentication is very bad news. We've known that for decades. It became the first resort anyway†. The RFC this author is complaining about (which is a decade old at this point) is just yet another way to use passwords. Stop it.

If you actually wanted to build one of these today you would not build one of those toy digest systems, you'd use a PAKE such as OPAQUE https://tools.ietf.org/html/draft-irtf-cfrg-opaque-01

But arguably instead of dedicating effort to trying to "fix" password authentication it's better to just do much less of it. On the web that means much more WebAuthn.

† This mistaken inversion happens a lot. When working on the British railways there is supposed to be an assessment of the safest practical method of performing the work. What used to be known as "red zone" working, where there are still trains using the railway while you work on it, is inherently dangerous and to be avoided. Red zone should be a last resort. But in practice what you will routinely find after a red zone accident is that they picked red zone not out of necessity but simply their planners had fallen into a habit of always justifying this unsafe practice rather than choose methods that might delay things, inconvenience workers or require purchasing equipment. It had become their first resort instead.

Thanks for the link to OPAQUE. It looks indeed much better than SCRAM-SHA, I like how the draft underlines that "clients never disclose their password to the server, even during registration."

Do you know if/when it is considered for implementing in the major browsers? Given that even SHA256 digest implementation is missing and that OPAQUE seems much harder to implement, I wouldn't be surprised if it takes another decade.

Regarding not using passwords at all, unfortunately this is not something I can use as a web user with 100s of logins.

No, I doubt it would be considered for browsers in the immediate future. OPAQUE was chosen by CFRG as the asymmetric PAKE that IETF protocols should choose by default in future. If you're designing a new protocol and it needs (or should usefully have) an asymmetric PAKE, then the IETF would prefer OPAQUE.

For a web browser, as I wrote, the correct thing is to push hard for WebAuthn.

You are correct that as a user, today, you are obliged to have some sort of password store if you want reasonable security, but that's a constraint imposed by the past, rather than a way forward.

Are there usable PAKE implementations? Audited ones?

There is value in using PLAIN inside of TLS instead of SCRAM-* methods. If you use SCRAM-, you're committing your password storage to only* use that method for storing the plaintext. So if you were state-of-the-art 20 years ago and used CRAM-MD5, and then you wanted to upgrade to SCRAM-SHA-1 when that came out... you don't have a good migration story, since the password storage has the information needed to validate CRAM-MD5 but not SCRAM-SHA-1, and there's no way to regenerate the information for SCRAM-SHA-1 without the plaintext password.

But if the authentication server gets the plaintext password, it can validate it against the old CRAM-MD5 storage, see that it matches, and then update the storage to SCRAM-SHA-1 on the fly. The entire process is invisible to the user, who gets a security upgrade in the process.

There's another class of use-cases, where a service needs to authenticate a user based on a token from another service. But for this, it's better to dispense with passwords entirely and instead go to something like Kerberos, where the authentication service gives you tokens in lieu of any password information.

> If you use SCRAM-, you're committing your password storage to only* use that method for storing the plaintext.

I consider this an advantage. I know how the password is stored, and if the service wants to update the storage, than it has to ask me to reset my password. If it doesn't ask me so, how can I know that they are up to date?

> The entire process is invisible to the user, who gets a security upgrade in the process

or never gets a security upgrade, and he has no idea.

Reply on news.ycombinator.com