This synopsis is a guest post by Matt Hucke (@matthucke), a developer at AutoAccessoriesGarage.com and one of the first people I met this year at Windy City Rails! It covers Justin Love’s talk on SQRL.
Shared secret password security is “rotten at its core”.
With a memorable image involving monkeys sharing far too much, Justin Love (@wondible) exposed the fundamental problems of typical web site password setups. What we want in an effective authentication system, he says, is unique identities, not reused from site to site, to protect us from the inevitable breaches that are far too frequent these days. A hack of Target or iCloud should not result in our email accounts also being compromised – for users will reuse passwords across sites, no matter how often we tell them not to.
Public / Private Key cryptography is the best tool we have. The public key – which can and should be shared far and wide – does not contain the information in the private key, but it proves that we have a matching private key.
“Secure Quick Reliable Login”, with its amusingly-pronounced acronoym, uses public/private key pairs linked to smartphone-friendly QR-codes. As an out-of-band transmission, it’s also resistant to malware on the user’s computer.
The master private key belongs to the user. If the server is compromised, no harm done – nothing is stored there that must remain secret.
SQRL client apps on the user’s device will guide the user to create a master key, which never leaves that device (backup on paper, to be placed in safe deposit box, is advisable). With this master key, a site key and identity key pair are generated for a particular remote resource.
For the web developer, it’s as easy as loading the SQRL gem and invoking its methods to parse a query. Storing public key information is left to the site’s developer – or may be handled by such popular solutions and flexible solutions as Devise.
SQRL is so secure and seamless that users could even log in via malware-riddled public terminals without fear of permanent account compromise. More importantly, SQRL users need not worry about a breach of one account leading to a breach of something far more important – banking or email – as happens so frequently today with password reuse.