3 ms·

From http://srp.stanford.edu/demo/ http://srp.stanford.edu/demo/ "This demo requires a browser that supports both JavaScript and Java." There's nothing modern

From http://srp.stanford.edu/demo/ http://srp.stanford.edu/demo/ "This demo requires a browser that supports both JavaScript and Java." There's nothing modern about a system that requires Java in the browser. No thanks.

erinaceousjones 6y ago
> The SRP JavaScript demo has been tested successfully under the following browser environments: > > Mozilla 1.x, Netscape 6, 7 > Netscape 4.x - JDK 1.1.5 w/bignum support required > Internet Explorer WindowsNT 4.0 (IE4) 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/KeyServerProtocol https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...
amaccuish 6y ago
SRP is good. Apple uses it for HomeKit. The HomeKit pins you use are authenticated by SRP. The page is just a really old demo, the protocol itself is still sound and some have come up with variations for more security. Also it has the ability to generate a session key.
- tialaramex 6y ago
  SRP is... weird. 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.
Spivak 6y ago
It's an educational demo for students to learn about the protocol ya nincompoop. The actual protocol is language independent and only really requires that the client do I teeny bit of lifting. 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.
tomato2juice 6y ago
That's an ancient demo, I guess I should have linked a modern implementation sorry. More info here : https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

erinaceousjones 6y ago

> The SRP JavaScript demo has been tested successfully under the following browser environments: > > Mozilla 1.x, Netscape 6, 7 > Netscape 4.x - JDK 1.1.5 w/bignum support required > Internet Explorer WindowsNT 4.0 (IE4) 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/KeyServerProtocol https://wiki.mozilla.org/Identity/AttachedServices/KeyServer...

amaccuish 6y ago

SRP is good. Apple uses it for HomeKit. The HomeKit pins you use are authenticated by SRP. The page is just a really old demo, the protocol itself is still sound and some have come up with variations for more security. Also it has the ability to generate a session key.

tialaramex 6y ago
SRP is... weird. 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.

Spivak 6y ago

It's an educational demo for students to learn about the protocol ya nincompoop. The actual protocol is language independent and only really requires that the client do I teeny bit of lifting. 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.

tomato2juice 6y ago

That's an ancient demo, I guess I should have linked a modern implementation sorry. More info here : https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...