TLS isn't up to the job without better credential protection, says RFC As part of the long process to make the Internet more secure, user credentials need better protection than the transaction layer security (TLS) standard. A new experimental-level, RFC-7804, proposes applying a 2010 protocol called SCRAM for the purpose. While TLS protects plaintext passwords handed to servers over HTTPS, the …
"There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS."
Such as?
It briefly mentions that the database can be stolen for offline cracking, but not if the passwords have been salted and key stretched.
but Melnikov says it “failed widespread deployment and has had only limited success”
Only because the client-side implementations are poor quality for end users to use and I wouldn't expect a protocol change to affect that. Any new protocol is going to have the same issue because it probably won't deliver the UX improvements that are badly needed- and honestly we need those before we need new protocols.
Also not for nothing but we shouldn't be building new crypto-based authentication systems without crypto-based 2FA built into them from the ground-up. Or at least demanding in the protocol that the user stores support them.
To this day, the UI is a fugly as it's physically possible to be. Also browsers offered no ability to logout without using a nasty hack.
Form-based authentication sucks because it's inherently phishable. That could be solved by browsers, if a baked-in password dialogue hashed the origin + credential to an intermediate result.
As for 2FA, this inevitably means phone authentication. Great for banks and such, but I'd never switch that on for my "normal sites", first because it's all a bit web-hostile, in that it ties security to another device other than the primary browsing device. But mostly because I don't want to store the users mobile number. The most secure way to store people's private information is to not store it.
Given the privacy implications of ISPs storing domain names, and some servers front many domains so you usually can't get away with the IP number alone, what about having two layers?
The first is a certificate, etc, for the numeric IP address so you know the URL will be secured, and the second is the same sort of thing for the URL to authenticate that the domain name matches. That way all a snooping ISP can see is the numeric request, such as 104.20.24.212, and nothing more personal such as www.theregister.co.uk
Assuming El Reg gets round to security at some point...
SCRAM has to send the salt and iteration count to the client, which means an extra round trip and leaking information to an attacker posing as a client. While leaking the salts isn't fatal, it'd be better if it could be avoided.
The SCRAM design could be fixed by using a One-Way Accumulator rather than an HMAC, but if you're going to do that (elegant as it is), you might as well do a bit more work and implement a Zero-Knowledge-Proof authentication mechanism. We already have TLS SRP suites, so there's no need to add SCRAM suites to TLS.
The extant SRP suites aren't ideal (no GCM ones, for example), but they're decent and adequate for most applications, and they're pretty widely supported (OpenSSL, GnuTLS, etc). Or use a strong TLS suite like ECDHE-RSA-AES256-GCM-SHA3841 and do SRP at the application-protocol (HTTP) or application layer.
(There are other ZKP protocols, such as PAK-RY, but SRP is the most widely used.)
1It's unfortunate that suite uses AES-256 rather than AES-192, since the AES key-scheduler flaw makes the former weaker and more expensive than the latter, but in practice AES with ~172 bits of effective key is still more than strong enough for most purposes.
If we're going to standardise anything, it should be a mutual password authentication mechanism - that is, the client and server must both prove they know the underlying password, without revealing it. There's a mechanism like that in section 4.3 of the TCPCrypt paper:
http://www.tcpcrypt.org/tcpcrypt.pdf
The risk with mutual auth is always that the server leaks something that can be used to brute force the password. Not sure how that mechanism stacks up, but would certainly be safe for strong passwords as the hash functions could easily be specified as a proper password hash like Argon2.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
