5 ms·
It solves the problem with offline password cracking, but it introduces the need to trust a third party. Since the client side of SRP can be implemented in Jav
by chalst 13y ago
It solves the problem with offline password cracking, but it introduces the need to trust a third party.
Since the client side of SRP can be implemented in Javascript [1,2,3], there's not really much in the way of compelling reasons not to use it.
[1]: There's a client in the SRP bundle at http://srp.stanford.edu/download.html http://srp.stanford.edu/download.html
[2]: https://github.com/symeapp/srp-client https://github.com/symeapp/srp-client
[3]: https://github.com/clipperz/javascript-crypto-library https://github.com/clipperz/javascript-crypto-library
- nly 13y agoOne of the key aspects of SRP is it provides mutual authentication. The server is considered untrusted until authenticated. If you run it in Javascript you lose the benefits it has over simple challenge-response client authentication. TLS-SRP could replace ordinary CA based server authentication, but I think there's a middle ground somewhere. Both are complimentary. CAs should be authenticating servers to my browser, and SRP should be authenticating servers to me.
- chalst 13y agoThis isn't quite right: you still keep the benefit that the server in no sense has a copy of your password, and it is publically visible what the program is that implements the client-side authentication. That said, I agree that there are strong benefits to having support for SRP in the browser.