The Secure Remote Password Protocol
The recent Heartbleed debacle had me remember a project a decade ago where the version of weblogic was upgraded but the script failed to deploy the matching version of the apache plugin. Fortunately we contracted a pen test firm who threw a load of custom perl script attacks at the site before we let the public in. They found that the error responses being thrown back to the attack scripts were just like Heartbleed; raw chunks of memory containing whatever was passing through the web server after having been decrypted.
I rang up the pen testers on their second day to ask them how they were getting on. They had already obtained the head of customer supports username and password doing a checkout on the upgraded production parallel environment. We had what is known as a ‘Code Brown’ with that news until the version mismatch was found and fixed.
Such genuine mistakes, as well as badly implemented and unnecessary security extensions, can leave your customer passwords lying on the table. (It is just me, or does the idea an optional diagnostic feature on an encryption product sound like a terrible idea? But I digress…) Then there is the risk of an ‘inside job’ where someone who you are paying is snooping for passwords. Large employers decrypt your https and scan for unauthorised traffic. Big laptop providers install things like superfish to decrypt customers HTTPS traffic to sell smart ads on pages. This means bad guys working in the offshore network support teams of very large firms with tens of thousands of employees (your customers), can be snooping for passwords used on your site, passed over a even a well configured, and usual secure, HTTPS connection. Then we have large laptop makers pre-installing bad root SSL certs to inject ads into your web pages which make you totally wide open to password interception. All-in-all passwords are the same sort of liability as a slippery bar of soap in the showers of a maximum security prison.
At this point the old salts are yawning and mumbling about “two factor authentication”, “public key cryptograph” or even “ssl client certificates” being for the serious money websites. Anyone who cannot use such approaches has to live with the inherent risks of passing a password. Nothing new to see here folks, move along…
Yet why not just use the standard, patent free, zero knowledge password proof algorithm “SRP 6a” so that the password does not have to cross the network?
To quote wikepedia verbatum:
The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to dictionary attacks mounted by an eavesdropper, and it does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server.
One would think that it had been custom designed in response to Heartbleed. Yet it was created last century, is patent free, and has been hanging around long enough to get some serious scrutiny. Had it been in widespread use, as it appears to deserve, the reputational damage done by Heartbleed could have been significantly reduced. Particularly in the window where Heartbleed had become public knowledge and folks were ‘helpfully’ demoing it by cracking large sites (aka showing off to their friends).
The real mystery is why doesn’t everyone know about it and use it?