At Clipperz we are huge fan of cryptography as a tool to empower users and protect freedom, therefore we are beholden to all the people who contributed to the development of this science. Among them a special thanks goes to Tom Wu who invented SRP, the Secure Remote Password protocol, at Stanford University during the late nineties. Today SRP is a widely appreciate authentication method and it is our choice for Clipperz online password manager. Tom Wu was so kind to answer some of our questions about SRP and its chances to gain even more traction in the future.
SRP is provably more secure than most authentication protocols used by online service providers. Which are the main obstacles to its widespread adoption?
TW: In many ways, SRP represents the “best of both worlds” when it comes to online authentication using a human-memorized password. In a nutshell, it provides security against both passive and active network attackers, a level of security that traditionally required some form of public-key infrastructure to obtain, without the overhead and cost of maintaining such an infrastructure. Instead it leverages the strength of the shared password, which is already being managed, and imposes no additional infrastructure requirements on the application.
Ironically, this is also precisely the biggest political obstacle SRP faces, because it in effect cuts out the middleman and allows direct user authentication without expensive infrastructure to secure that initial connection before sending the password. It is understandable and commonplace that corporations that sell a product would be opposed to alternatives that eliminate the need for that product, even if the alternative is a net win for the end user. In past years, implementors were concerned about strong password protocols because most of them had patent restrictions, but because SRP has a well-established free license, those concerns have fallen by the wayside and SRP can move on to the next phase.
Incidentally, because SRP does not store plaintext passwords on the server side but instead uses what is known as a “non plaintext-equivalent verifier”, it may indirectly help with problems like the one recently occurred to Reddit.
Are you aware of any online service that uses SRP?
TW: The best example is probably GoToMyPC. Their security white paper (pdf) is an excellent resource and describes how SRP is used to secure end-to-end communications between the client and a remote host computer based on shared knowledge of a password. (See also the related Certicom press release.)
Would you recommend JavaScript to implement the SRP steps on the client side?
TW: It wouldn’t necessarily be my first choice of programming environment, but it is possible to do the large number arithmetic required by SRP in JavaScript. Naturally, one concern would be performance, both in terms of loading the code and executing the protocol steps. Another concern, which is ever-present with pure JavaScript apps, is the phishing attack; how do you know the page you are seeing is really executing the SRP protocol and not just sending your password to the attacker?
This is a very challenging aspect of designing and implementing security on the Web. As long as these concerns are addressed and managed, though, JavaScript can be a viable environment to implement an SRP client.
Is the Stanford SRP Authentication Project still alive?
TW: The Stanford SRP Authentication Project has largely served its purpose already in getting the word out about SRP and hosting a reference implementation of an application suite secured with FTP. Nowadays, most of the real work is going on in standards bodies like the IETF, IEEE, and ISO, as well as on the “front lines” with implementations such as yours.
How could we contribute to the SRP project and success?
TW: What you’re doing so far is definitely on the right track.
I think this area is one in which Open Source software has a big advantage, because it can move quickly on an idea and not be burdened by bureaucracy or politics, but instead can focus on delivering security to the end user using the best technical solution. All it takes is some courage and persistence.
So keep doing what you’re doing - stand as one more example of how SRP can be used as part of an Internet security solution. To that end, I really should be asking you what I can do to contribute to your project’s success.
Thanks for the opportunity to speak out on a subject very important to me.
Delicious
Digg
Reddit
Facebook
Yahoo
Netscape
StumbleUpon
Now, I
Now, I’m sure that the protocol is great and cryptographically secure and all, but this interview doesn’t seem to address the key problem that in an active attack, the attacker can replace any data being sent. Sure he does say that it will only work “As long as these concerns are addressed and managed”, but he fails to acknowledge that anything which can solve your problem, already solves the whole problem of defending against an active attacker, because currently the only solution is https, and any other solutions would be either to pointlessly specific to getting any Zero knowledge Password Proof protocol working verifiably in a browser, or like https, would already provide a method whereby the channel would be safe from passive and active network attacks.
So it really looks like the author is trying to blame the lack of success for his protocol on the web, on things which are completely minor compared to the fact that protocols such as his are pointless when it comes to web apps.
SRP is not an SSL replacement
Dear Kuza55, since SRP provides both parties with a shared secret, one could even be tempted to see it as replacement for HTTPS, but I agree with you that today this could not be a feasible approach.
However a flawed authentication protocol within an SSL/TLS channel isn’t certainly good for the security of any web application. (Clipperz will use SRP to authenticate its users, but within an HTTPS connection.)
I believe that the main obstacle to the adoption of SRP is the computation load to be performed on the client side, i.e. by the browser itself. Browsers have no built-in math and BigInt libraries to be exploited by web apps, hence implementing SRP requires an heavy use of Javascript or running a Java applet. Complex the first, not convenient from a usability perspective the second.
Being SRP well analyzed and patent free I think there are little excuses to opt for less secure protocol. Also because today you don’t need to write code from scratch but simply include code from our own implementation! ;-)
Anyway I’m very proud to be read and commented by competent security experts like you! Marco
I doubt I
I doubt I’d call myself an expert on anything, but anyway. Adding yet another layer of encryption on top of SSL would really only help you if SSL was broken, because if SSL is not broken there is no way to even get access to the cipher text that is being sent back and forth by the algorithm, and at the point when SSL is broken, since you are relying on SSL to get the code to the client securely, we’re back to the problem of running SRP on an unsecured channel being pointless in the face of an active attacker.
So you are still at the mercy of the secure SSL connection remaining in tact, and you are adding needless complexity to a system, which gives no real gain, but degrades performance because of all the arithmetic both the client, and especially the server (which is already under the weight of SSL) have to do.
And very often an attacker doesn’t need your password, sure its better for an attacker if they can obtain it, because it is often reused, but simply having access to the system you are using (via appropriating session tokens), as is often the case in XSS/CSRF attacks, you will still be able to force the victim to perform the actions you want them to.
So even if we had the code stored elsewhere, (e.g. in an extension), we would still have problems because if we are on an unsecured channel our session tokens would be exposed to even a passive attacker.
Furthermore, the idea of the middleman is also not a particularly bad one, because you are able to verify a site without having had any prior contact with it.
So even if SRP was used to determine an encryption key which was then used to encrypt the whole session, when a user first visits a site and registers, they have to transmit the shared secret over an unsecured connection.
Which is worse than SSL where using public-key infrastructure it is possible to determine whether the certificate is genuine (if its signed properly of course).
What I think we all agree is a bad thing though, is the enormous prices charged by some root CAs, and that that is something which has to change, but people have already realised this and started efforts like CACert ( http://www.cacert.org/ ) which will sign people’s certificates for free, currently they are only included in Mozilla browsers by default, but I think they are still working on trying to get into IE.
So while I think these algorithms are extremely interesting, I don’t think they have many applications on the web, and we should just support community based efforts to remove the high costs of having a signed certificate, or work on solutions which fit the needs of the web more closely.
Kuza55, you got it wrong
Kuza55, SRP is NOT Diffie-Hellman. It is resiliant to man-in-the-middle attacks. Read it up on wikipedia, it’s all there. The SRP RFC provides a good overview of the protocol and why it does not have the vulernability you mentioned.
While Diffie-Hellman attempts to only create a shared key, SRP attempts to create a key and verify a password at the same time.
I am not a crypto expert so
I am not a crypto expert so the terms may be totally wrong, but I see it differently.
I think the problem they mentioned is not in the protocol but in the application. You have to negotiate the session with the website by “logging” in (transferring the non-plaintext verifier stuff) to get your keys. The problem is if the site is impersonated before hand and all of the javascript is replaced to send your password in plaintext to the attackers.
So the question is how do you verify the code from the site is trusted in the first place….
SRP is awesome though for eliminating brute force attacks.. which is what we really need.
Re: I am not a crypto expert so
SRP is not the silver-bullet for security; it is just a very useful component.
We have tried to give a full overview of how an online application willing to handle sensitive data could be build: anatomy of a “zero-knowledge web application”.
The problem of checking that the code running on the browser is the legitimate one is still very tricky; we have some ideas on how to solve it, but we still have a lot of work to do.
Post new comment