12 ms·
SQRL - Replacement for usernames and passwords
- yogo 13y agoVery interesting solution. I haven't listened to Security Now in a while but it's good to see Steve Gibson thinking about these things.
- nfoz 13y agoHow does this compare to OpenID? Seems similar except with the premise that a user is their own identity provider, which is a QR-code-reading app on their smartphone. I like!
- y0ghur7_xxx 13y ago> How does this compare to OpenID? It's completely different. You don't need to remember an url, you don't need to remember a password, there is no third party involved in the authentication process, ... I could go on, but it's really a completely different authentication mechanism.
- tptacek 13y agoHow is this better than any other phone-based 2-factor auth scheme?
- __david__ 13y agoWell, it's not really 2-factor is it? It's just the phone part of a 2-factor login and no web form part. Presumably the screen shot that showed a login form was for people without the phone app.
- elliottcarlson 13y agoIt's not - it's really just a password manager. The "something I know and something I have" is completely removed by only requiring you to have the phone. If it's a password manager, then that is what it is; if it's meant for security, then it comes back to the recent article on fingerprints not being a password.
- lstamour 13y agoI dunno about the fingerprints analogy, that's still more boneheaded -- I mean, I can change digital secrets a lot easier than I can change my fingerprints ;-)
- richardjs 13y agoIt's not really a password manager--there's no shared secrets. The site identifies you by a public key. For authentication, it gives you a nonce, and you sign it with the corresponding private key. All the secrets are kept on your device. I've wondered about the "something I know" dimension as well. Perhaps a passphrase could be used (it already is used to secure the master key). It'd still be a major improvement, as only your local device would need it, and you wouldn't have to have a separate password for each site.
- elliottcarlson 13y agoRight; I guess password manager was a bit of an over simplification there - sorry about that, as was the fingerprint analogy - I guess it's more a concern of someone having my phone and thus instant access. An additional factor would help with that by bringing in the "something I know" dimension.
- richardjs 13y agoYeah, that's a concern of mine too. Looking deeper at the description, looks like he describes a passphrase-like "local password" on the "The user's view of the application" page [1]. Hopefully that would address that issue (at least as much as passphrases do for SSH keys). (And no problem. If we were forced to comment using only precise terms, with no simplifications, comments would either be ridiculously long or nonexistent.) [1] https://www.grc.com/sqrl/userview.htm https://www.grc.com/sqrl/userview.htm
- veesahni 13y agoIt's 1 step. Just scan a code. Con: requires internet connectivity, unlike some 2-factor implementations
- lstamour 13y agoBeyond that there's no explicit second-factor here, if you don't have Internet, what are you proving your identity to? If local, then run a local server...
- gbhn 13y ago2-factor can be done in the post-password sense (require the second factor after this SQRL step), or alternatively, the algorithm the phone does could use a second factor at that point.
- eximius 13y agoWell, theoretically you could make an implementation which reads the QR code then displays what would have been posted to the server. Via a web-browser extension, you could then type this into a form field and have that log you in. You could base<something> encode it to make it a little easier. So, it seems feasible offline with online required only for convenience.
- jonny_eh 13y agoIsn't access to the internet already required to log into any internet site?
- imrehg 13y agoMeaning Internet access for your phone. The example in the article being login at the library - the library computer has Internet access, but your phone has to also connect to a wifi (if there is one), or the mobile network (if you are 3G subscriber and there's reception). Then factor in that you might go abroad, I don't know many places where they just give free internet access to anyone with a smartphone...
- richardjs 13y agoThat's a question I have. One potential answer is that it moves authentication out-of-band, in case there's a keylogger or other malicious mechanism of the machine you're using. Also, it removes the need to remember a separate password for every site. Your master key is secured with a password, but that's it. It also removes the need to have a shared secret with a site, and doesn't require any third-party involvement. He spends a good chunk of the latest episode of Security Now [1] describing it's advantages over current schemes. The episode isn't up yet (I listened to it on the the site's live stream), but it should be soon. [1] http://twit.tv/sn http://twit.tv/sn
- juhanima 13y agoNot exactly a new idea. Here is some prior art http://openaccess.uoc.edu/webapps/o2/bitstream/10609/14761/6/dpintorTFM0612memoria.pdf http://openaccess.uoc.edu/webapps/o2/bitstream/10609/14761/6... http://www.computer.org/csdl/proceedings/ares/2009/3564/00/3564a578-abs.html http://www.computer.org/csdl/proceedings/ares/2009/3564/00/3... As far as I know, QR-TAN is being used in Germany for authentication by a number of banks.
- drivebyacct2 13y agoNot only that, Google's OpenSesame did the exact same thing and worked for all Google users until they pulled it after it "went public". So then they pulled it, told us something better was coming and nearly two years later, nothing.
- phpnode 13y agodrivebyacct2 - your account has been dead for about 100 days and 200 posts, basically no one can seen your messages unless they have showdead on. Here's the "offending" post that you were banned for https://news.ycombinator.com/item?id=5982741 https://news.ycombinator.com/item?id=5982741 (hint - the ban is completely unjustified)
- DanBC 13y agoAhem. (https://news.ycombinator.com/item?id=5974604 https://news.ycombinator.com/item?id=5974604)
- phpnode 13y agodidn't see that, but even so, this is still a horrible punishment
- drivebyacct2 13y agoDan is right. I assumed that was why I was hellbanned and I was clearly behaving poorly in that thread. Fortunately, since they brilliantly combined a hellban with a slowban, I knew immediately. I'm not really sure why I keep posting - figured I goofed [that thread is embarrassing] and I'd feel dumb groveling to have an account unbanned when people create one-off troll accounts everyday here. Though it is frustrating when I see entire threads go on about bits of technology and then my comment is the only one pointing out some super relevant related tech. Oh well.
- veesahni 13y agoInteresting - so you generate a key pair on your phone (this is your identity and can be backed up to a printable QR code). Then, to login to any site, you scan a QR code displayed beside a login form and your phone can verify it''s identity (i.e. proves that it's the holder of the key pair). Perhaps on the first sign-in, the site will ask for an email address or some details to create an account for you.
- umsm 13y agoThis is an interesting concept. The authentication should be safe to be transmitted on the same network... What about if the phone and computer are on the same (i.e. WiFi) network?
- dsl 13y agohttp://attrition.org/errata/charlatan/steve_gibson/ http://attrition.org/errata/charlatan/steve_gibson/ > Steve Gibson is somewhat of a "fringe" charlatan. In some professional security circles, he is not considered a reputable security professional, rather more of a snake oil salesman peddling third-rate software with bold claims. While many of his claims are a bit outlandish or bold, few, if any, are demonstrably false. However, when asked to speak on security topics, Gibson is getting adept at putting his foot in his mouth. A single amusing quote may be laughable, but a series of them begin to paint a picture of someone who doesn't really understand security. Rather, he seems to know enough buzzwords and ideas to be dangerous to his clients.
- richardjs 13y agoNot to use a debate cliché, but isn't this a ridiculously shameless ad hominem? He's published the protocol and disavowed any intellectual property claim to it. Let's focus on critiquing the protocol.
- dsl 13y agoAn ad hominem attack would be attacking him for unrelated traits, i.e. "we can't trust people with blue eyes!" I believe his history as a snake oil salesman is highly relevant to his current "security" work.
- richardjs 13y agoSure, if you're using an appeal to authority as part of the argument in favor of the protocol. Hopefully we're relying more on logical analysis of the protocol than we are on the proposer's authority, in any security context. Isn't that one of the points of open protocols?
- bargl 13y agoActually it's still ad hominem. The fact that you completely ignored the original post and instead attacked Steve Gibson, is indicative of an ad hominem attack. If you'd even said, this new idea is ridiculous because QR codes are inherently insecure (which is false) you'd be fine. Sources: http://plover.net/~bonds/adhominem.html http://plover.net/~bonds/adhominem.html I think this example is pretty much what you did. A: "All rodents are mammals, but a weasel isn't a rodent, so it can't be a mammal." B: "I'm sorry, but I'd prefer to trust the opinion of a trained zoologist on this one." B's argument is ad hominem: he is attempting to counter A not by addressing his argument, but by casting doubt on A's credentials. Note that B is polite and not at all insulting. If you want further reading from other sources you can go to any of the following links. en.wikipedia.org/wiki/Ad_hominem http://www.nizkor.org/features/fallacies/ad-hominem.html http://www.nizkor.org/features/fallacies/ad-hominem.html http://c2.com/cgi/wiki?AdHominem http://c2.com/cgi/wiki?AdHominem
- mixologic 13y ago"because the private key required to create the signature never leaves your smartphone." Sure. People never get their phones stolen, never buy new phones, people never irreplaceably destroy their phones dropping them in a toilet.
- bargl 13y agoHe points this out himself under "Among the problems we have solved to create a practical solution, are:". It is toward the bottom.
- richardjs 13y agoHe described a local password (basically a passphrase) on the "The user's view of the application" page[1]. [1] https://www.grc.com/sqrl/userview.htm https://www.grc.com/sqrl/userview.htm
- artjumble 13y agoThis all sounds interesting, but I was just thinking this would be a great way to unlock a computer. Scan the 'lock' screen with your phone. Probably not good for an office environment (too easy to grab someone else's phone), but I would use it at home.
- derefr 13y agoThe thing this is most similar to is Twitter's recent 2FA implementation. Except, instead of the site automatically pinging the app to open on your phone (and then you ACKing or NAKing the ping), it requires you to open it yourself and scan a code on the screen (thus implicitly ACKing it.) Everything else happens the same.
- donmcronald 13y agoIt seems like the basic idea isn't unique. I was thinking of something similar a while back and found https://tiqr.org https://tiqr.org while looking for similar ideas.
- asgentile 13y agoThinking about the user experience for this. I want to authenticate, so I hunt down my phone, launch an app, scan a code, press a button in the app to submit. This seems to me like quite a long process versus the traditional typing in a username and password. What about the implications of a stolen phone?
- richardjs 13y agoWith the traditional username/password system, you have to remember a unique, secure password for each site--or else you use a password manager, which involves more steps as well. He's also mentioned that this could be adapted into a browser plugin, so that would streamline use on a trusted machine. As for losing the phone, he suggests a passphrase-like "local password" on "The user's view of the application" page [1]. [1] https://www.grc.com/sqrl/userview.htm https://www.grc.com/sqrl/userview.htm
- jimueller 13y agoSeems similar to the discontinued Google Sesame. http://www.zdnet.com/open-sesame-googles-no-password-log-in-1339329832/ http://www.zdnet.com/open-sesame-googles-no-password-log-in-... It would be interesting to know why Google didn't pursue it. Maybe a 20% project? https://plus.google.com/101935995649723391317/posts/P94xEz9DjCo https://plus.google.com/101935995649723391317/posts/P94xEz9D... Another similar system http://corp.galois.com/blog/2011/1/5/quick-authentication-using-mobile-devices-and-qr-codes.html http://corp.galois.com/blog/2011/1/5/quick-authentication-us...
- seldo 13y agoHow do you log in to a mobile site if you have to use your phone to scan the code?
- donmcronald 13y agoA mirror and a front facing camera :-)
- jensenbox 13y agoWouldn't you need at least 2 mirrors to correct the image?
- cjp 13y agoA front facing camera already flips the image so that the user sees what they usually see when they look in a mirror. So one mirror would end up being right. Except when you open the camera app, the mobile site is no longer displaying the QR code.
- teleclimber 13y agoI assume that in addition to the QR code there would be a link that would trigger an intent to open the authentication app with the necessary data. At least on Android that's how it could work.
- chj 13y agoA minor problem is that auth app has to return back to the browser with a new link which the browser may not be able to open within the original login tab.
- teleclimber 13y agoI don't think that is the case. After the auth app communicates with the server you just need to click the login button on the original page. I don't think the auth app needs to load a specific url.
- josephwegner 13y agoSo, this is essentially a less cool version of getclef.com , right?
- josephwegner 13y agoSo, this is essentially a less cool version of getclef.com , right?
- rpledge 13y agoThis is very similar to my project at http://qrauth.com http://qrauth.com
- lisper 13y agoAnother replacement for usernames and passwords: http://dswi.net/ http://dswi.net/ Note: the SSL certificate on the demo server has expired. I'm working on getting it renewed, but this is just a demo anyway.
- habosa 13y agoThis looks like a much less polished version of Clef (https://getclef.com/ https://getclef.com/). Clef is a really awesome app and they're already powering this type of integration for a few hundred websites. One of the founders is an HN regular, although I can't remember his username (Jesse, reply if you see this).
- jessepollak 13y agoThat's me, thanks! We're glad you think we have a little more polish, but to be honest, we're really excited about any replacement to passwords making waves in the tech world. Ultimately, no single group is going to be able to tackle this problem alone, so the more critical thought we have, the better off we all are. If anyone has any questions about Clef, I'd be happy to answer them, but I also don't want to distract from the discussion going on around this proposal.
- Mithaldu 13y agoOne question: What's keeping you from developing a desktop client, so i can login without needing my phone around? From what i can see on your website, Clef simply uses a key stored on the phone to generate a password† that is then sent to the website to be logged in behind the scene. There shouldn't be anything stopping a user from using a program for this on any os, as long as it has the ability to obtain the nonce‡ from the website and the user-unique key. † password used here in the loose sense of being a user identificator including both the identity of the user and a secret unique to the user ‡ which is even more simple than a QR, as it's simply a barcode, albeit an animated one (the animation doesn't factor into the value at all, right?)
- jessepollak 13y agoNothing is stopping us from a technical standpoint. Multiple devices is something we plan on adding, but we're being really careful about it because it increases complexity and introduces more vectors of attack. We also think that a phone is tied to a user's identity more than a computer or a tablet, so that's what we're really focusing on. Give the flow a shot and let me know what you think.
- blibble 13y agogoogle did this last year: http://www.zdnet.com/googles-open-sesame-login-ditches-passwords-3040094830/ http://www.zdnet.com/googles-open-sesame-login-ditches-passw...
- Mithaldu 13y agoThis is functionally the same thing as https://github.com/habnabit/passacre https://github.com/habnabit/passacre , only tied to a cellphone in exchange for sparing the user the burden to remember their login. It would be interesting if the SQRL website code would also display the nonce under the QR and the user could download a desktop program to paste the nonce in. Even if it weren't open source, as long as both windows/linux binaries are available, people could even set it up on a server of their own so they'd just paste the nonce at a private url.
- jaequery 13y agoi love the site's design
- peterwwillis 13y agoHere's why this is stupid: This is 1-factor authentication, but it's actually LESS secure than a username and password. A password is something you know - it's in your head, so it can only be stolen if you save it somewhere, or if there's malware on your computer sniffing it. The tokens in the phone are saved in the phone, so if you lose the phone, you've just lost your password/set of keys. On top of that, malware in the phone can extract the keys. With malware on your phone, your accounts can be pilfered without your knowledge, at any time. Or if your phone is stolen. This is different from 2-factor, where you have to both know a secret AND have access to a device. (If the prospect of malware on your phone doesn't phase you, consider that news articles over three years old reported hundreds of thousands of malware installs found by various security companies)
- patrikr 13y agoThe key on the phone is of course encrypted with a password.
- DanBC 13y agoMalware on the phone isn't covered by their attacks and weaknesses page. (https://www.grc.com/sqrl/attacks.htm https://www.grc.com/sqrl/attacks.htm) The Userview page seems to miss that point as well: (https://www.grc.com/sqrl/userview.htm https://www.grc.com/sqrl/userview.htm) > In other words, only the smartphone's owner can use the system to assert their identity, and nothing will prevent them from asserting their identity whenever they wish to. I think they mean "only the person currently in possession of the smartphone" ... except they go on to say that whoever has the phone has to identify themselves to the phone using a strong password. > The SQRL system was specifically designed to eliminate username and password authentication to remote websites. But controlling access to SQRL authentication itself requires the smartphone's owner to prove their identity to their own phone. > And to that end, “a secret only the user knows” is still the best technique for users to repeatedly, quickly, easily and privately prove their identity to their own smartphone. > The cryptographic design of the SQRL system inherently provides identification security for every website it contacts. In that sense the system itself is fully secure without any password protection. We refer to the SQRL password as a “local password” because it is only used to prevent others from using the SQRL smartphone app to impersonate its owner.
- DanBC 13y agoThey don't offer a reference implementation. The documentation provided is a bit rambling and jumps around; it has stuff people don't need and doesn't have some stuff people do need. It's a bit scary to think that people are going to implement some crypto stuff based on just this and release it into the wild as a secure solution. There's a similar problem with password safes - some of them seem secure enough, but there are many and who knows whether those are any good or not.
- EugeneOZ 13y agoI feel is something missing in that algorithm of check. And... Not all services are web, not all web services are public (so mobile app will not be able to open url), and U don't understand why bots will not scan that QR.
- deleted 13y ago[deleted]
- nly 13y agoI think you can MITM this by presenting legitimate (proxied) ycombinator.com QR codes on e.g. ycombigator.com. The app would still authenticate to the legitimate site and then 'activate' the session, and ycombigator.com could have at it. HTTPS won't help either. The problem is there's no way for the phone app to transfer additional secure session cookies back to your desktop browser, so this has to be the case. Sure, the app will display the legitimate domain or URL but the user probably thinks that's what they're viewing on their desktop anyway, so will likely accept. Requires mutual authentication.
- gcr 13y agoThis attack can be stopped by referer checking. A site that hosts a QR code should display a warning instead of the QR code if the referer doesn't match.
- nly 13y agoThe malicious site in the middle can download the legit QR server side (e.g. using PHP) and simply spoof the referer, then present it to the visitor. Where will a referer check help?
- gcr 13y agoThat's a great point. I didn't think of that.
- phpnode 13y agohttps does not expose referrer, and you are logging in through https, right?
- e12e 13y agoNice system - but there's not even a proof of concept? Or am I missing something?
- ijansch 13y agoHave a look at http://tiqr.org http://tiqr.org for an existing implementation of this same idea. Complete with open source server implementation and android/ios apps (which are open sourced too).
- Sami_Lehtinen 13y agoQuick + / - analysis: - "But no two visitors will ever have the same ID". - How is that confirmed, generating random 512 bit keys do not guarantee never having same ID. It's just quite unlikely. - SQRL lacks strong web-site identification, that's a bad thing. Domain name isn't strong authentication. I would like to include strong site identity with within the QR-key. (Evil website attack, NS spoofing / MITM) + No shared secrets is a real bonus. Except, if the attacker has full access to the site already and steals password, they can steal everything else. Therefore if password hashes are stolen, it's major breach of security, and all passwords should be immediately reset. Of course nobody's using same password for separate sites. So, site was breached and thats it anyway. / Out-of-band authentication, well, in some cases yes, in some cases no. I wouldn't call this true out of band solution. Especially when using mobile browser, or shared WLAN connection. Fact that authentication data is also routed on same internet route at the server end sounds quite likely. Of course this can be fixed by service provider if they really want to do it. + No third-party, that's the only way to go. In anycase when there's a third-party, the solution already sucks badly. That's one of the main reasons why I hate most of SSO solutions. (Single Sign On) - Mobile (nor desktop) devices aren't secure, having keys in mobile device isn't considered to be secure and those can be extracted. Default mobile device protection isn't good enough for password / identity protection. Most of people aren't even using simple 4 digit pin. Real + would come form completely separate authentication device. - Using long password with mobile is horrible. My GPG private key password is 20+ chars including tons of special chars. Try typing that with mobile, repeatedly. If shorter passphrases / keys are used, not enough entropy is included. - "A password lockout system". Eh? Same method should prevent any web-site password hacks too. ;) Anyway, with proper password, guessing should still be futile, read my statement about password earlier. If the password got even 128+ bits of entryopy, it's going to be long guessing marathon. I don't really care even if you try to guess 1 or 10000 pwd/seconds. / "such as a personal safe deposit box" - Is not truly secure, what a joke stament. - Document doesn't describe how identity authentication is linked to the actual client logging in. Basically this would mean that there has to be cookie version of cryptoraphic challenge, or some other data linked to that, which has to be stored for a while at web-servers end. Could this be used to create resource consumption DDoS attack on the service? That's one of the reasons why I don't like solutions which require web-server to maintain state for non-logged in users.
- joetech 13y agoI don't like this as standalone authentication, but as part of a 2-stage scenario, I would use it.
- dlucci 13y agoCorrect me if I'm wrong, but couldn't this still be susceptible to DNS Spoofing? This goes under the assumption that the URL has not been tampered with, if I'm not mistaken?
- jbert 13y agoI think this is pretty the same thing as storing a secure cookie? Except the 'cookie' is the private key on the phone, so it's tied to the phone not to a particular browser. Other than that, I don't see a difference between the two? I think this is basically a long-lived session cookie, stored out-of-band. I also don't see how the public/private keypair changes anything. Why not just store the nonce on the phone? If the nonce has only ever gone over https to the user, no-one else will know it.