Title: SQRL: revolutionizes web site login and authentication Post by: chsados on October 13, 2013, 09:33:08 PM 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 (https://www.grc.com/sqrl/sqrl.htm).
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:
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?
This simple and straightforward SQRL protocol yields a surprising array of features and benefits: Anonymous Identification & Authentication:
Anonymous Identification & Authentication:
Secure and practical anonymous identity authentication can use a first-party protocol while delivering extreme ease of use. The LACK of third-party involvement
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:
Practical Considerations:
The following pages continue to describe this SQRL system:
Title: Re: SQRL: revolutionizes web site login and authentication Post by: jimbobway on October 14, 2013, 03:45:16 AM 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/ Quote 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:
Caveats and notes:
Title: Re: SQRL: revolutionizes web site login and authentication Post by: jchysk on October 14, 2013, 04:03:47 AM 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. Title: Re: SQRL: revolutionizes web site login and authentication Post by: CIYAM on October 14, 2013, 04:07:24 AM 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. Title: Re: SQRL: revolutionizes web site login and authentication Post by: hivewallet on October 14, 2013, 01:12:38 PM Love this kind of stuff. Keep pushing forward, guys.
Title: Re: SQRL: revolutionizes web site login and authentication Post by: Sukrim on October 14, 2013, 02:16:43 PM 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)? Title: Re: SQRL: revolutionizes web site login and authentication Post by: integrity42 on October 14, 2013, 02:23:30 PM This is awesome. Keep up the good work! It's about time we move away from basic logins and passwords. 2FA is a must
Title: Re: SQRL: revolutionizes web site login and authentication Post by: wtfvanity on October 14, 2013, 02:45:25 PM 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. Title: Re: SQRL: revolutionizes web site login and authentication Post by: JWU42 on October 14, 2013, 02:48:05 PM 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"
Title: Re: SQRL: revolutionizes web site login and authentication Post by: RAVENCROW on October 14, 2013, 02:55:14 PM At first glance this seems amazing can't wait to look into implementing something like this on my webpage !
Title: Re: SQRL: revolutionizes web site login and authentication Post by: VTC on October 14, 2013, 03:23:48 PM 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. Title: Re: SQRL: revolutionizes web site login and authentication Post by: wtfvanity on October 14, 2013, 03:26:10 PM I enjoyed the unfinished attacks and problems page from his website:
Quote 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... Title: Re: SQRL: revolutionizes web site login and authentication Post by: minimalB on October 14, 2013, 08:46:46 PM 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?
Title: Re: SQRL: revolutionizes web site login and authentication Post by: traderjoe on October 16, 2013, 02:07:17 AM 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. Title: Re: SQRL: revolutionizes web site login and authentication Post by: minimalB on June 16, 2015, 09:50:31 PM Nice demo here:
https://www.youtube.com/watch?v=2QQ-Hi7npbM Title: Re: SQRL: revolutionizes web site login and authentication Post by: Kprawn on June 17, 2015, 07:08:53 AM 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. ??? Title: Re: SQRL: revolutionizes web site login and authentication Post by: CIYAM on June 17, 2015, 08:17:11 AM 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. Title: Re: SQRL: revolutionizes web site login and authentication Post by: minimalB on July 15, 2015, 09:25:13 AM 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). |