SQRL:
Beyond Passwords
Password Based
Authentication
is broken
for both 2 party and 3 party authentication schemes
Problems with username/password authentication
- Security Breaches (Adobe, PSN, US Gov't)
- Users don't understand security
- Malware, Keyloggers, Viruses
- Corporate Firewalls may decrypt SSL
2 Party Systems
- Ad hoc, different and arbitrary characteristics & requirements
- Many very poor implementations
- Credentials routinely escaping
- Users bear burden of protecting themselves
- Don't reuse passwords
- Don't use known answers to "security questions"
- Remember passwords and answers without writing it down
3 Party Systems
- Facebook, Google, LinkedIn, other OAuth providers
- No one trusts these providers to be truly secure in the post-Snowden age
- Hosted by for-profit companies
- Proprietary (even when using OAuth standard)
- Still relies on 2 party authentication to the 3rd party site
SQRL
Secure Quick Reliable Login
A highly secure, comprehensive, easy-to-use replacement
for usernames, passwords, reminders, one-time-code
authenticators … and everything else.
Created by: Steve Gibson
Twitter: @SGgrc
Features of SQRL
No shared secrets (via public/private key encryption)
Anonymous identification & authentication
Support for multi-factor authentication
Strict seperation of identities
No third party involvement
Easy to use
Open source specification*
*There have been claims that the authentication
method SQRL uses is patented, but Steve Gibson has
addressed this and claims the methods described in the
patent work completely differently than SQRL
and so do not apply.
SQRL in a nutshell
(cue groans)
With SQRL you either tap, snap, or click a login page's QR code and YOU are securely logged in.
How SQRL Works
- User generates one "Master Identity" for everything, forever. (A randomly chosen 256-bit token.)
- The website's login presents a QR code (a SQRL link) containing the URL of its authentication service, plus a nonce
- The user's authenticating device signs the login URL using a private key derived from its master secret and the URL's domain name
- The authenticating device sends the matching public key to identify the user, and the signature to authenticate it
This means:
- Users present a unique identity to each site (no tracking via identity)
- No per-site data needs to be stored on the client
- Web servers have no secrets to keep
- Web servers that are compromised cannot disclose anything that would compromise other sites
- Since the nonce is unique each time, prevents reuse/replay attacks
The SQRL Client
SQRL requires a client installed on either the same device or on the user's smartphone
Same device login
The SQRL client registers the SQRL protocol on the machine, and when the SQRL link is clicked, it responds to the SQRL link to authenticate the user
Cross device login
Using the SQRL client on their smartphone, a user can scan the QR code which will provide the data to the client to authenticate the user
Demo
Problems (and solutions)
Need the SQRL client installed before you can use SQRL
- Will need education of users and developers for adoption to take off
Problems (and solutions)
User DOES need to authenticate to their SQRL client
- TouchID can be used in some cases (iPhones, some Android), but using a traditional password for the client is also an option
- In no scenario does the user need to share their SQRL password with anything other than the installed client
- It moves the authentication issue from an untrusted 3rd party (any web server) to a trusted device
- Only need to enter full password once per "session", after that only a hint pin (defaults to first 4 chars of password)
Problems (and solutions)
No 3rd party so no external recourse
- Forgotten passwords
- Malware on device steals SQRL identity
SQRL Rescue Code
- An offline, high-entrophy, 24-digit random generated number
- Generated when SQRL identity is created
- Never stored on any device, so cannot be stolen
- Power 1: Forgives any lost/forgotten password, allowing for password reset
- Power 2: Unlocks SQRL's "Identity Lock" for identity management (allowing for changing SQRL identity on a 3rd party)
Identity Lock
Bad guys who gained control of an identity can not lock users out of their own accounts, but users can use the Identity Lock (and Rescue Code) to change their identity and take back their identity
Known attacks
- (offline) Brute force - SQRL uses SCrypt for a time-consuming, memory-hard password process to validate password to protect against brute force attacks
- (online) Spoofed URL - attacker could gain logged-in session. SQRL presents domain in the client for the user to verify before authenticating
- (online) Man-In-The-Middle - If the attacker has this power, authentication is the least of the user's problems
Technology
- Colin Percival's Scrypt for "memory-hard", acceleration resistant password-based key derivatio.
- A deliberately time-consuming PBKDF2 construction, using XOR-sum chaining with Scrypt as its PRF, to render brute-force cracking orders of magnitude more difficult and daunting
- Dan Bernstein's "NaCl" 25519 elliptic-curve cryptosystem
- EdDSA (elliptic curve digital signature system)
- Elliptic curve Diffie-Hellman (via a scalarmult on EC)
- Cross-platform "Libsodium" library
- Misc. crypto pieces… SHA256, SHA512, HMAC256, etc.
Where is SQRL today
Reference libraries are functional, other implementations are in progress: some a proof of concept and others are fully-functional implementations
Client Support
Server Support
In summary
- Encourages one identity for everything.
- Secure against website breaches (no secrets to keep).
- Pseudonymous, prevents tracking. Users choose to de-anonymize.
- Simple, straightforward, open, non-proprietary, completely free.
- Provably secure, understandable and easily auditable.
- Most complexity in the client to ease server-side development.
- Can co-exist side-by-side with existing identity & authentication methods.
- Low-friction adoption… so perhaps it has a chance ?