SQRL: revolutionizes web site login and authentication

[chsados]

Have you guys looked into this proposal of using QR codes for secure and anonymous logins?  This was theorized by Steve Gibson and the original white paper can be found here. 

A short video describing SQRL can be viewed here: http://youtu.be/ZrQboo3pA10

This seems really interesting and I think a bitcoin address could be used as a user's master key.

A user wishing to log into a website will be prompted with the following:

Wishing to login to an online service where an “SQRL” code appears nearby:

• The user launches their smartphone's SQRL app, and lets it see the QR code.
  (Or a smartphone / tablet user taps it.  Or a laptop / desktop user clicks on it.)
• For verification, the SQRL app displays the domain name contained in the SQRL code.
• After verifying the domain, the user permits the SQRL app to authenticate their identity.
• Leaving the login information blank, the user clicks the “Log in” button... and is logged in.
  (A bit of page automation could even eliminate the need to click the “Log in” button.)

Even though it is THAT simple, it is FAR
more secure than any other login solution.
(We'll define exactly what “far more secure” means, below.)

What happened behind the scenes?

• The QR code presented near the login prompt contains the URL of the authentication service for the site. The URL includes a securely generated long random number so that every presentation of the login page displays a different QR code. (In crypto circles this long random number is known as a “nonce.”)
• The smartphone's SQRL authentication app cryptographically hashes the domain name of the site keyed by the user's master key to produce a site-specific public key pair.
• The app cryptographically signs the entire URL contained in the QR code using the site-specific private key. Since the URL includes a secure long random number (the nonce), the signature is unique for that site and QR code.
• The app issues a secure HTTPS POST query to the QR code's URL, which is the authentication service for the site. The POST provides the site-specific public key and the matching cryptographic signature of the QR code's URL.
• The authenticating web site receives and acknowledges the POST query by returning a standard HTTP “200 OK” with no other content. The SQRL app acknowledges the successful submission of the user-signed QR code.
• The authenticating site has the URL containing the nonce which came back from the login page via the user's smartphone. It also has a cryptographic signature of that URL, and the user's site-specific public key. It uses the public key to verify that the signature is valid for the URL. This confirms that the user who produced the signature used the private key corresponding to the public key. After verifying the signature, the authenticating site recognizes the now-authenticated user by their site-specific public key.

This simple and straightforward SQRL protocol
yields a surprising array of features and benefits:

Anonymous Identification & Authentication:

• SQRL ID:  Visitors to a website are uniquely identified by an absolutely anonymous SQRL ID. Their “SQRL ID” is simply their public key, described above, a 256-bit number. The same visitor always presents the same ID every time they visit the same site. But no two visitors will ever have the same ID. Thus a single website can uniquely and anonymously identify every one of their visitors.
• SQRL IDs are both user AND site specific: Although the same user always presents the same ID to the same site, they present an entirely different ID to every other site they visit. There is NO WAY TO ASSOCIATE the SQRL ID presented to one site with those presented to any other sites. In other words, there is absolutely no cross-site coupling of identity. Users are free to use their SQRL identity anywhere and everywhere because every site receives its own unique SQRL ID.
• No annoying account creation: Suppose you wish to simply comment on a blog posting. Rather than going through the annoying process of “creating an account” to uniquely identify yourself to a new website (which such websites know causes them to lose valuable feedback traffic), you can login using your SQRL identity. If the site hasn't encountered your SQRL ID before, it might prompt you for a “handle name” to use for your postings. But either way, you immediately have an absolutely secure and unique identity on that system where no one can possibly impersonate you, and any time you ever return, you will be immediately and uniquely known. No account, no usernames or passwords. Nothing to remember or to forget. Your SQRL identity eliminates all of that.

Anonymous Identification & Authentication:

• Identification vs Authentication:  SQRL-enabled websites have only your unique SQRL ID to disclose, and it is useful only to that single site since every users SQRL ID is automatically unique for every site they visit. There need not be any username or password for sites to have compromised, lost or stolen. Your SQRL ID does not authenticate your identity, it only identifies you to that single website. Authentication requires the SQRL smartphone app to cryptographically sign a long random number and return it with your SQRL ID (your public key). Thus, even if a hacker were to obtain your stored SQRL ID, it is useless for impersonating you—even to that one site—because the private key required to create the signature never leaves your smartphone.
• No keyboard interaction:  Imagine that you want to login to a computer at an unsafe location such as a library or a hotel. With SQRL, your login occurs without entering any personal credential information into the computer. You provide no username or password that might be captured by a keystroke logger or resident malware. The website issues an “SQRL authentication challenge” in the form of a unique SQRL graphic code. If you have an SQRL smartphone app, it takes up the challenge and sends the website a unique challenge response that can only have come from you. The website then logs you in when you click “Log in” under the still-empty login form. From the standpoint of that computer—and anything it might contain that's attempting to spy on you—you are magically logged in without your credentials ever appearing or passing through. Your smartphone's SQRL application saw the site's SQRL code, instantly identified you to the site, and provided cryptographic proof that the person who just clicked the “Log in” button . . . is you.
• No “shared secrets” with websites:  Six-digit time-based authenticators are based upon a cryptographic secret known only (we hope) to your smartphone and the authenticating website. This allows the website and your phone to agree upon which six-digits will be shown at any time. While this has the benefit of always changing, it repeats the username and password problem of needing to always be kept secret . . . which websites continuously demonstrate is beyond them. (And remember, the employees of those websites do have access to your credentials.) Also like passwords, because they are not truly secure, you must employ a separate and unique authentication sequence for every website you use. If this were to become popular and widespread, you would soon be scrolling through hundreds of six-digit numbers to find the right one.
• Out-of-band authentication:  In the context of an untrusted computer, we mentioned above how website visitors were almost magically logged in without touching the computer's keyboard. This is one aspect of an important security principle known as “out of band.” The principle is that it is generally more secure not to send all aspects of a secure communication through a single channel because the security of that channel may be compromised. Entering your username, password, and one-time password all through the same keyboard is worrisome “all in band” authentication. Difficult though it might be to compromise the security of any single channel, it is vastly more difficult to simultaneously compromise two very different forms of communication. Since SQRL uses a smartphone's connection to the internet, perhaps even a cellular carrier, it avoids reusing most or all of the local computer's channel. Authentication often occurs completely “out of band”, and thus invisible to any intruder monitoring the computer's communications.
• No third-party involvement:  In this era of pervasive government surveillance and US NSA coercion, who is going to trust any third-party with their identity? Other identity systems and solutions attempt to “federate” trust by creating a role for themselves as a third party with whom you establish a separate trust relationship. Then the authenticating website asks that third party to verify your identity on your behalf. It would be one thing if there were no alternative. But this page, and the pages that follow, demonstrate that secure and practical anonymous identification can use an entirely first-party protocol while delivering extreme ease of use.

Secure and practical anonymous identity
authentication can use a first-party protocol
while delivering extreme ease of use.

The LACK of third-party involvement

• The use of a third-party “middleman” transfers much of the responsibility for the management of your online identity to an external facility. In an era of secret national security letters compelling the disclosure of whatever the government desires, that's a serious liability (as mentioned above), but it can also be a significant benefit: If your smartphone escapes from your control, you need only tell the third-party to cancel the phone's authentication authority and you're immediately protected from malicious use of your smartphone's identity assertion.
• This SQRL system concentrates ALL authentication authority into the smartphone. The benefit is that no one else has the keys to your online identity.  No one.  But the liability is that YOU are then absolutely responsible for maintaining the security of your online identity.

Ultimately, someone has to be responsible for your identity.
Should it be you, or someone else?

This is a serious issue that needed to be addressed.  Our solution is to provide the user with a conceptually simple set of tools to dramatically ease the burden of assuming and managing this responsibility. As subsequent pages detail, the system provides extensive cloning, backup, local password protection and reset capability.

Hold on a second . . .  We send the website a signed bunch of gibberish?  That's it?
Yes.  And that's exactly the point.  SQRL provides absolutely anonymous identity authentication (IA). Users are identified only by a random “opaque token” and each unique combination of user and website creates a unique identity token. Thus, every user presents a unique identity to every website they visit. It is up to the user and the website to then (optionally) bind the user's unique SQRL identity to a real-world account on the website.

For example, Amazon's account management might have an option to associate a logged in user with their Amazon SQRL identity. So Amazon would present a unique SQRL code on the account management page. The user simply snaps it with their smartphone's SQRL app and now Amazon can add their SQRL ID to their account. From now on, the user can login to Amazon anywhere with vastly improved security just that easily.

And it would probably work the other way around too: Amazon's login page would present traditional login fields and a SQRL code on the side. An existing Amazon user who is establishing their SQRL identity snaps the SQRL code with their new smartphone app and Amazon replies that it does not recognize the user. If they wish to create a new account, they may do so here, or if they are an existing user, please use traditional login one last time to associate their new SQRL identity with their existing Amazon account.

Defending against the dark forces
Why we prominently display the domain name BEFORE authenticating:  The smartphone has no way of knowing the website the user is visiting. It only receives the domain contained in the QR code displayed by that page. In the "Evil Website" attack (also discussed on the attacks page), a malicious website pretends to offer an SQRL login for itself (www.we-are-evil.com), but instead it obtains and displays a login QR code from some other domain (www.amazon.com) where an SQRL user may be known. The SQRL app always identifies and authenticates its user to the domain contained within the (human unreadable) QR code. So an unwitting user, who didn't know the domain they were authenticating to, would be logging themselves into a session initiated and controlled by the Evil Website, thus allowing the Evil Website to impersonate them.

Note that even in this instance, none of the user's login credentials ever become known to the Evil Website. The Evil Website only gets a spontaneously logged-in session (though that's clearly not a good thing!)

This risk can be easily thwarted, however, simply by having the user's smartphone first prominently display the domain name it will authenticate to only if the user first gives it permission. The user knows they are visiting “www.we-are-evil.com.” So if their phone asks for permission to login to “www.amazon.com” they just say no.

Trusting the app: Though it should go without saying, it's better to say it: Until SQRL support is moved into the underlying smartphone OS, and is then curated perhaps more carefully, users will be responsible for choosing and installing an SQRL client into their smartphones. As the SQRL system gains in popularity, it is foreseeable that malicious developers might create malicious applications to steal their users' credentials. This is not a problem that's in any way unique to SQRL. Any sort of identity or password manager needs to be carefully vetted before it is entrusted with important information. The standard advice here is to stick with the herd and go with the solution that's been most thoroughly examined, checked out, and proven.

Three Ways to Go . . . smartphone optional:
(And we solve the XKCD problem above!) Although the original inspiration for the development of this system was a smartphone scanning a QR code on a website's login page, a small addition to that model enables two more significant modes of operation: Simply make the QR code image also a clickable link to the same URL that's encoded into the QR code. This yields three ways to login:

• Scan the code with a smartphone:  Using the model described above, a user's smartphone scans the QR code appearing on a website's login page and the user is logged into that site.
• TAP THE CODE on a smartphone:  To login to a website ON the smartphone, when the visual SQRL code is also a URL-style link (using sqrl:// as the scheme) the SQRL app installed in the smartphone will receive that link and securely log the user into the site on the phone.
• Click the code on a desktop or laptop screen:  To use the SQRL system on any desktop or laptop system, a desktop SQRL application would be installed and would register itself to receive sqrl:// links. (This is similar to the way an email program registers to receive mailto: links.) This allows the same solution to be used by users on their desktop that they are using on their smartphones. When any website offers an SQRL code the user just clicks on the code with their mouse cursor and the locally installed SQRL app will pop-up, prompt for their SQRL password, confirm the domain, and then log them in.

Practical Considerations:

• Open & free, as it should be:  The component techniques and technologies employed by this solution are all well known, well tested, well understood, unencumbered by patents, and exist in the public domain. The entire system can be readily assembled from 100% open source algorithms, packages and libraries.
• The chicken & egg problem:  There was a time before the Internet, when people asked: If there are no high-quality websites no one will use the Internet; and if no one is using the Internet no one will bother creating high-quality websites. Somehow it happened anyway. We hope and expect that SQRL login will be like that. Once we have established the required interoperability standards, people WILL create free smartphone SQRL clients—probably many. And as websites begin to offer SQRL login as a side-by-side alternative to the traditional username and password, SQRL popularity will grow. Why would anyone NOT use it when it's free, perfect, and just works? Users will want it because it immediately eliminates the most annoying aspect of the Internet. Website visitors will demand it and websites will soon see that they are losing visitors by not offering the instantaneous SQRL option. Now that we have such a terrific egg, it's difficult to see what's going to keep it from hatching, surviving, and growing.
  
• NSA & NIST-free cryptography:  The recommended implementation of this system leverages several unique characteristics of well-known cryptographer Dr. Daniel J. Bernstein's (DJB) carefully designed twisted Edward's curve digital signature algorithm (EdDSA). In his extensive and complete papers (linked herein) Bernstein explains the detailed derivation and properties of his “25519” elliptic curve. Importantly, there are no mysterious constants or “magic numbers” of unknown provenance. Dan has a long and well-known history of fighting for cryptographic freedom. In 1995, while a student at the University of California, Berkeley, Dan brought a lawsuit against the United States (represented by the EFF) challenging the restrictions on the export of cryptography . . . because he wanted to publish a paper and associated source code of this “Snuffle” encryption system. The ruling in the case declared software as protected speech under the First Amendment, and national restrictions on encryption software were overturned. (He won.) Please see the Detailed Crypto Architecture page for full detail and discussion.

The following pages continue to describe this SQRL system:

• Introduction & overview
• The user's view of the application
• Detailed crypto architecture
• Web server responsibilities
• Attacks, weaknesses, vulnerabilities
• Implementation details
• Implementation resources
• Projects and finished applications
• Room for growth: More than auth?
• Other related QR code login work
• Frequently Asked SQRL Questions
• Feedback about SQRL & these pages

[1713946483]

1713946483

[1713946483]

1713946483

[1713946483]

1713946483

[1713946483]

1713946483

[jimbobway]

jgarzik posted this on reddit that is somewhat related:

http://www.reddit.com/r/Bitcoin/comments/1nkoju/bitcoin_core_dev_websites_do_not_need_passwords/

Introduction: A Rant

The bitcoin community has a long, and somewhat disappointing history of creating poorly secured websites, whose password databases are inevitably stolen.
Thankfully, most bitcoin websites are at a minimum using hashed password databases. But we can do much, much better.
If you are building a website that has the potential to be securing thousands or millions of dollars worth of BTC, please consider digital signatures as one method superior to standard passwords. Give your users, at a minimum, the option to avoid the terribly insecure practice known as the "password" -- a practice where humans have been proven time and again to choose passwords poorly, and reuse passwords across multiple websites.

A Solution: Digital Signatures
If you have a bitcoin address, you have access to an as-yet-underused feature: Through ECDSA digital signatures, you may prove you control that bitcoin address without ever need to reveal a password or private key.
This could be used by any website, to eliminate any need for website passwords.
When you visit a website and need to login, the website displays a long random string, e.g. "Auth a%fdgER@#gvv5sad#SJN23"
The user uses their bitcoin client to digitally sign "a%fdgER@#gvv5sad#SJN23"
The user enters their username and digital signature into the website, and normal login process continues. User is now securely authenticate via this digital signature.

Benefits:

• A password or secret is never sent to website.
  Website never accumulates a hashed-password database, for criminals or court orders to data mine.
  User experience can be seamless with easy plugins.
  I'm sure someone, somewhere is working on a browser standard to make digital signatures work in a browser, without a plugin.

Caveats and notes:

• Security is intentionally simplified here a bit, for purposes of example.
  Two-factor authentication is still a good idea. Digital signatures are simply one, highly secure method of authentication.

Who here has a preferred digital signature plugin? Do we need to write one?

[jchysk]

SQRL seems to have some gaping holes in the design: http://security.stackexchange.com/questions/43374/could-sqrl-really-be-as-secure-as-they-say
Check out launchkey instead: https://launchkey.com

As far as that rant goes. I think digital signatures can be done in HTML5 within the browser without a plugin. Although I have seen plugins for specific identity solutions that deal with browser keys, so perhaps it's difficult.

[CIYAM]

I had also come up with a similar idea - although to make sure the hand device does not get hacked I had envisioned a QR code being scanned back from the device's screen to then complete the login (via web cam) with your authenticator being being a "completely offline" device (i.e. safe from any potential online threats).

Also the Trezor may be able to provide similar sort of OTP authentication down the track.

[hivewallet]

Love this kind of stuff. Keep pushing forward, guys.

[Sukrim]

So if I use this on my desktop system, your service then gets not one but 2(!) IPs from me (mobile phone + desktop) that it can correlate + 2 browsers to fingerprint...

Why not just use Google's 2FA scheme salted with a user name (since it only maps to 6 digit numbers to make manual input possible)?

[integrity42]

This is awesome. Keep up the good work! It's about time we move away from basic logins and passwords.  2FA is a must

[wtfvanity]

So if I use this on my desktop system, your service then gets not one but 2(!) IPs from me (mobile phone + desktop) that it can correlate + 2 browsers to fingerprint...

That was exactly my first thoughts. The entire OP repeats over and over and over again ANONYMOUS!!!

WTF do you mean anonymous? You have two separate devices communicating with the server. You have TOR on the first one, but what do you have on your phone? Anonymous sounds absolutely fucking retarded as the key points.

If you mean, not providing a secret to the server, okay, I understand that, but anonymous should never be used in SQRL's sales pitch in its current design.

Going to Edit this and add some more.

So, target site, amaz0n.com gets a unique nonce from amazon.com and sends it to the user, asking for validation, when validated, let's bad guys log in. It also says how secure it is against xss but it sure sounds like it flat out lets an attack log right in as the user no questions asked if they can get them to their phishing site.

The ramifications of a stolen or compromised master key for every single site... just sound awful.

[JWU42]

Listened to this on a recent SN episode.  It has a way to go and anonymity is NOT the goal.  Not sure why/how that got included in Steve's "pitch"

[RAVENCROW]

At first glance this seems amazing can't wait to look into implementing something like this on my webpage !

[VTC]

QR code scanning takes too much time.  I propose a better solution.

Using something similiar to chirps.io
Ex: https://bips.me/checkout/mobile/cb

1) User runs app on phone that listens on mic (optional: app can start automatically via a push from a browser plugin)
2) User visits website and presses button to begin html5 audio recording (optional: auto allowed by whitelist)
3) Website sends a 'chirp' (optional: perhaps can be done on soundwaves that are barely inaudible to humans)
4) App on phone computes signature and sends it back as a 'chirp'
5) You are now logged in

Done this way, this app nor the phone requires internet access! Increased privacy.
With all the optional features, logging would be as simple as just visiting a website.
For increased security: Phone can display confirmation to proceed including the website url.

Audio chirps are a lot more passive than scanning qr codes.  But why not even do away with the chirps and have a browser plugin that communicates directly over tcp with the hardware wallet (phone) for signature.  No need to confirm url as there is no way to spoof it since the browser plugin will be able to verify it.  And can have chirps/qr codes as a back when phone has no internet.

[wtfvanity]

I enjoyed the unfinished attacks and problems page from his website:

Lost Phone “Attack”
< to be written >
• Okay... not really an attack, but we need to address the consequences.

Umm... the consequences being that the average idiot won't have a backup of their master key, and now cannot log into ANY website. The second one being, if it is not password protected, they can be impersonated on ANY website...

[minimalB]

This SQRL login principle looks great! "Projects and finished applications" link is confusing (at least to me). Is there a working prototype somewhere to try out?

[traderjoe]

Someone, maybe on reddit, was asking how this applies to bitcoin.  Well, the answer to protecting private keys recorded as QR codes, he comes up with is to use memory-hard encryption that takes 60 seconds to validate an attempt.  For me, that type of protection would be the holy grail that would let me keep backups of my paper wallet(s) as QR codes without having to worry about securing the QR code somehow (in a vault, etc).

Did anyone else get excited about that part of Steve Gibson's thoughts about how to implement his SQRL authentication idea?  That part is perfect for bitcoin users.  I am hoping it inspires ethiopei to implement that kind of encryption on armory paper wallets.

[minimalB]

Nice demo here:
https://www.youtube.com/watch?v=2QQ-Hi7npbM

[Kprawn]

I have watched this on youtube and followed the discussion on Reddit.

I have some questions.... or possible flaws... but I am still reading more about this, and do not want to shoot it down, before I investigated further.

1. Can a hacker get between the router and the pc, and intercept the QR Code being send to the user?
2. In a public setting, someone could intercept the login, by scanning the QR Code before the user scan it?
3. Do they send different QR codes for every login? {How random is this seed?} 

This is a nice concept, but it's still early days for it... The concept is solid, but the implementation need a bit of tweaking to make it more secure. {In most instances, the weakpoint are on the user side}

I can see more complex "screen capturing" malware being done in future, when they go mainstream with this idea.  

[CIYAM]

1. Can a hacker get between the router and the pc, and intercept the QR Code being send to the user?

Not if you are using HTTPS (which I assume they would be recommending).

2. In a public setting, someone could intercept the login, by scanning the QR Code before the user scan it?

It wouldn't really matter if they did as they don't have the private key needed to create the response QR (which ties into the next question).

3. Do they send different QR codes for every login? {How random is this seed?}

It uses a *nonce* so presumably it will never repeat such a value twice and no future nonce value would be able to be predicted (assuming the server has a good source of entropy).

I had the exact same idea back when I was creating the CIYAM Safe (as it uses QR codes for 100% air-gapped offline security) and I think it is likely to be the future for authenticating.

To make it even more secure if the smartphone was surrounded by a "see through" Faraday cage (which will still work with QR codes) then your authenticating device would be safe from being hacked.

[minimalB]

SQRL revisited (~45min watch):
https://www.youtube.com/watch?v=hsotcaizGjM&t=1h37m30s

Steve Gibson explained the concept quite in detail.
Final API is just around the corner.

I hope this is going to get mass adopted. I am not an expert, but to me it sounds bulletproof (if you treat your master rescue code in truly safe place).