Not anymore. Modern logins should use something like SRP, which doesn't send a password over the wire on every login.
There's nothing modern about a system that requires Java in the browser. No thanks.
I have a feeling that the page referenced is not so "modern" :-)
BUT, that doesn't make it a necessarily bad protocol for modern browsers to be implementing, i.e. as part of their "identity management" stuff, like Firefox Sync [1].
Remember that the Stanford Java applet implementation was purely academic, intended as a demonstration and developed at a time where JavaScript was too limited for the large number arithmetic they wanted to do (no BigInteger equivalent).
That purely academic implementation does not invalidate the work itself, or future implementations thereof.
[1] https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...
Also it has the ability to generate a session key.
The good news is that using SRP is definitely not worse than DH as a key agreement protocol.
The bad news is you probably already have a nice modern ECDH key agreement protocol, you wanted secure passwords and the proof for how SRP does that involves a lot of flailing about. Flailing about which so far reached SRP version 6a
If browsers and backend stacks and everything else was one config change from doing SRP 6a tomorrow it's tempting to say hey, go ahead it can't hurt.
But in fact SRP is very niche, so it makes at least as much sense to try to deploy OPAQUE or other things that have a clearer security rationale.
On any client where you can run code you can authenticate without ever sending your plaintext password over the wire. And on clients where you can't run code you can still accept the plaintext password as a fallback.
I don't see any plugins or libraries to add to any of the huge number of exiting authentication libraries. Has it even been subject to a hostile security audit? Has it been put in a place where it will face a serious state-sponsored attack and performed at least as well as existing systems?
Ya, the first time I heard of it I had the same reaction, but it's legitimate.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... That page is quite old, but lots of bodies use it: http://srp.stanford.edu/links.html
Amazon uses it in a service: https://docs.aws.amazon.com/cognito/latest/developerguide/am...
Also, as another commenter said, Apple uses it in Homekit.
Does anyone actually, no, not that I've seen.
I've never worked on a webapp that did this, though I have heard of it. What's the point, really, if you're using SSL? If you don't trust the server then don't use the service
It’s pointless client side. Trusting the clients hashing of a password is the same as using a clear text password. Aka some admin or hacker learns the hash they can use a modified client to send the hash directly.
Hashing on the client what the user actually types and sending that hash to the server which then treats that hash as the password can help in the case of users that construct similar passwords for different sites.
A user who uses passwords of the form "<site>.19%Gkm19^GB", for example, would normal be sending "gmail.19%Gkm19^GB" gmail, "twitter.19%Gkm19^GB" to Twitter, and so on. If anyone one of those gets compromised there is a good chance they all will be.
If the sites had a first step of client siding hashing then the password that gmail sees is "0d156132c43e7110b5d678eafd7117b5a4649fbf" and the one twitter sees is "cfd9d7f62b92eb025a242bc860d41aae60ebeacf". One of those getting compromised on the wire or at the server doesn't put the other at risk.
Not really, even if you have password hashing, the password is always in the clear when you're attempting an login or you're setting it. They can simply run the detection system then, without loss of security.