SRP and Browsers

Current Problems

  1. A user may be presented with a fake version of a web site by a third party (slightly different URL, or via man in the middle attack, or hijacked DNS). If the user enters their login credentials on this page, the third party steals them, and can use them on the real site.
  2. Users often reuse passwords. If a password is used on a site that is compromised, malicious, or intercepted (as above), other accounts may be vulnerable.

In short: users might send their passwords for sites to other sites. This is very bad.

Current Solutions

Security questions, special images, HTTPS, proper salting and hashing all help a bit, but nothing is going to stop a user from typing in their password on a lookalike site.

HTTPS relies on a central authority to give the valid site a cert, and not the impostor. If a user is smart enough to not enter their password on a site if the certificate is invalid, or not HTTPS at all, that helps, but its not too hard to get a HTTPS certificate. If it is hard, thats a problem (its hard to get for valid sites) and if its easy, its easy for impostors. it also relies on a third party (the certificate authority)

Asking security questions, personalized images, and all that related stuff is pretty vulnerable since the impostor can just access the real site, and forward the content as a regular man in the middle. Some of these schemes involve cookies, so its suppose to be suspicious if you get re-asked the security question (which happens if you don't have the cookie), but that happens often illegitimately, and I've never seen a site that explains this or works well (my bank is such an example, I get re-askeds the question every time, so its useless against man in the middle).

Asking people to make unique complex passwords is a good idea, but really, if someone has to have a different password for every site, attack 1 above still works, and the users is seriously annoyed.

SRP as a Solution

The HTTPS certificates attempt to inform a user of cases where they shouldn't enter their password. This is a good idea, but poorly implemented. (It has a lot of other benefits that it accomplishes very well, but thats another issue)

So how do we prompt users for a password in a way that can never cause harm? The first step is to make sure they don't avoid our solution: we need a way to easily allow users recognize the safe password entry area I'm about to define.

Requires some assistance from the browser level: if its purely done at the site level, it can be faked. Thus we need a extension to HTML, and browsers as well.

With this, the users should be able to avoid entering their passwords into areas that won't get our special handling.

Now for what the browser must do with these passwords. The answer is SRP. When the password is submitted, it will initiate a SRP exchange. This has some impressive properties:

  • it discloses no information to the receiver (or a man in the middle) about your password, other than allowing the legitimate server to verify if its correct. (There is a corresponding zero knowledge proof)
  • both parties (your browser, and the login server) receive a shared secret which can be used for encrypting your session.
  • your browser can determine if they actually validated your login attempt (they won't be able to decrypt your session if your password was wrong, or don't have the corresponding validator for your password).

This setup also has some other benefits: assuming each site you use properly selects a random key, using the same password across multiple sites is much safer. No traffic produced by a conforming browser from passwords entered into the SRP field would help login on a different site, even if you used the same password. Of course, key logging, or other general leaking of of the password by other means still could compromise multiple logins, so using different passwords is still better, but it is no longer really a bad idea to reuse the same password across multiple, even untrusted sites.

SRP also guarantees sites can to anything really stupid like store plain text passwords (in databases, or logs), or get modified to log the plain text passwords: they simply never touch a plain text password: it never leaves the browser.

This all works with no trusted authorities (you don't need a certificate).

My explanation here is simply how to use SRP to fix the issues with password use on websites, and a couple of notes about the security gains. For real information about SRP and its technical details do your own research. Stanford's SRP is a good place to start, and includes Competitive Analysis of SRP.

Sqrl is also a very interesting approach to this problem.

Copyright © 2011-2013 Craig Macomber