SQRL - Replacement for usernames and passwords
grc.com
grc.com
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.
† 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?)
One more question:
How about sites which don't have clef implemented? Can i enter a URL into the clef app (or use some kind of JS scriptlet to generate a QR code on the fly) and have it generate me the password for that, so i can type it in manually? Maybe even store usernames for such sites?
Right now Clef has zero use for me, as i've never even seen a website that implemented it. But something like that would at least add some use.
(Also i'm sad that you didn't confirm or deny the footnotes.)
1. exactly, we generate a digital signature similar to SQRL
2. right. from a technical perspective, the barcode is simpler than a QR code; however, it's actually proven really important from a usability standpoint. by animating the interaction, we have more control of the user's mental model of what's going on and can provide a much more intuitive user experience.
I've mentioned it elsewhere here, but i'd suggest you also look into https://github.com/habnabit/passacre , since its creators put a LOT of value in getting the crypto parts right and its main creator is very responsive online.
And thanks for answering the footnotes. It is an interesting thought that users can be helped by the wiggling animation of the barcode and its inherent suggestion. (That would be worth a trip report on how you got there.)
† I'd prefer to follow an rss feed, but your blog seems to be 90% marketing and only 10% user-relevant posts with no categories.
I'll definitely make sure to look over passacre; it seems great.
And no problem on the footnotes, if you ever have any more questions don't hesitate to email me at jesse at our domain name!
Clef is actually 2FA already because it relies on both possession (the device) and knowledge (the 4-digit PIN that protects the app). We're working right now to (optionally) replace the PIN with finger print scanning, when available. Either way, the knowledge (or biometric) portion is much more about asserting ownership of the device (if it gets lost or stolen, you can deactivate online) than as part of the actual authentication process.
It's not 2FA unless information flows between the user and the authenticator through two independent routes. For example, in Twitter's (and others') 2FA, information must flow between Twitter's servers and the user through the Twitter UI as well as through a GSM text message. That's 2FA.
Someone gets some malware on to the phone and gets the run of it. Records the pin, later steals the phone, or is able to replicate the entire device.
This could be guarded against if the pin changed every time and was delivered through an independent channel, which is what 2FA if all about. A complete, undetected compromise of a single device or a single information channel should not be able to defeat 2FA. That doesn't appear to be the case here.
We thought about building a mirror contraption that would allow you to scan the code on your own phone...sarcasm
send me an email, I'd love to help convince your workplace to integrate.
And who knows what happens on a mobile site or app.
Yuck.
On mobile, when you click the button, you're just redirected to the app where you approve the authentication request and are automatically logged in.
> 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.
I believe his history as a snake oil salesman is highly relevant to his current "security" work.
Doesn't mean it's not worth talking about, though. After all, science is entirely founded on a kind of inductive reasoning, so logical fallacies aren't crazy to consider.
Gibson's personality isn't the thing in question here, the quotation above is specifically about his history in security. If the comment was about how he's a major asshole (just an example, I'm not saying that) in conferences or something like that, it would be an ad hominem, as that sort of information would not be relevant.
His history as a security professional has no bearing on the actual content here. We are all talking about an idea SQRL not Steve Gibson. If you said, "SQRL isn't worth my time because I don't trust Steve Gibson" that's fine, but the author made no note on SQRL at all, he just attacked Steve Gibson and let it be.
Sure there may be precedence to say that SQRL isn't worth your time, but Steve's credentials don't affect this idea at all. For all you know he may have been given the idea by a team of security researchers who wanted to see if the top post on Hacker News would be some bull shit argument about Steve Gibson. Obviously not the case, but come on let's talk about the freaking content here not the man.
The saying "throwing the baby out with the bath water" comes to mind. Let's look at SQRL and see if it actually makes any sense before we throw it all away.
- Examples of Gibson's previous ideas that have been proven fake
- Examples of Gibson's previous projects that have security flaws
- Examples of projects that Gibson is purported to "peddle" through his "snake oil salesmanship"
- A quotable, referrable, expert opinion of Gibson's standing, or lack thereof, in the broader security community
The post includes none of those things. It is no better than saying "$NAME is a bad person!"; it merely uses more words to say so.
note that i am not affiliated with grc; my name is permuted :)
Attrition is itself the "expert opinion" of Gibson's standing, here's their Wikipedia page for more information: http://en.wikipedia.org/wiki/Attrition.org
So yes, regardless of what your link says, the argument is an ad hominem.
Bringing the quality of a person's previous work into the discussion is a necessary shortcut. We can't all be expected to have expert-level knowledge on everything.
Sources:
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."
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://c2.com/cgi/wiki?AdHominem
Also, you've presented no actual rebuttal of whether Gibson's history is relevant to evaluating his present claims. Rather you've merely stated the name of a logical fallacy. Which is, itself...
note that i am not affiliated with grc, my name is simply permuted :)
I think one of the main problems is that people in a field are generally critical of people who translate that field to a wide audience. You see that play itself out over and over. And that's what Steve does with his show, he tries to explain security to, more or less, laymen. And he only has an audio medium, which adds some difficulty. So, yes, he simplifies some things and this no doubt troubles a lot of security gurus.
Of course he's made mistakes on the show. I can recall a few, but most of them were caught and corrected later. He doesn't script it, so I'm sure you can find many examples of poor word choices or incorrect acronyms over the 300+ shows he's done.
I do think he's over-played the practical usefulness of some security products that he advertises on the show. I have experience with none of them (to my knowledge), but some of them just sound, to the trained ear, minimally useful. But, sadly, that's audio content advertising for you.
From the link, we have statements like:
> For whatever reason, Gibson tries to explain the Metasploit project as a "malware exploitation framework"
OK, that's a bad description. But he was describing Metasploit in passing using a description of Metasploit as it pertained to the subject at hand. And, if you read the actual transcript that they linked to, it was being used for malware exploitation. Seems like a silly nit-pick.
> You can't simply raise the spectre of global spying and hidden rootkits planted by Microsoft without either proving or disproving the allegation
No. If you see something alarming, you totally can. He didn't panic either.
> Steve said SSL connections are not susceptible to man-in-the-middle (MiTM) attacks? This is absolutely false.
Please. SSL/TLS has had vulnerabilities that allowed MITM attacks. They're ad-hoc and eventually get fixed. You can't just expect to MITM a random SSL connection. SSL is designed to be MITM-resistent, and saying "SSL prevents MITM attacks" is not in any way a bad description, especially when you're communicating to laymen.
> Further, having a switch does not absolutely prevent sniffing traffic. The popular Dsniff tool lets you do this.
Yep, he got that wrong.
> Close Steve, CSMA stands for Carrier Sense Multiple Access.
Yep, he got that acronym wrong. But I decided to check the next show[2]...
> [Steve] Also, I mangled an acronym, and I hate when I do that, especially acronyms that I know so well. I talked about CSMA, and I called it Collision Sense Multiple Access instead of Carrier Sense Multiple Access. And it has a CD on the end which stands for Collision Detection. [...] So the real acronym for Ethernet is CSMA/CD, which is Carrier Sense Multiple Access with Collision Detection
So he switched a word in an acronym, then corrected it next episode. But they complained anyway. I couldn't have scripted it any better to what I said above.
Those examples were skimmed from the first three links. The authors came across like they had a vendetta to nit-pick everything they could. They've blown their own credibility already as far as needless nit-picking, missing the forest for the trees, and not checking to see when he corrects his own mistakes (aka, doing their homework).
I'd hardly summarize all that as a "fringe charlatan". He may be a bit fringe-ish, but I don't see how he's a charlatan.
[1] https://www.schneier.com/blog/archives/2008/03/the_security_...
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)
The Userview page seems to miss that point as well: (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.
If you look at the crypto page the scheme he proposes uses an 'identity password' in combination with a strong KDF (scrypt). The resulting hash is XOR'd against the masked master device key.
This fact, together with grc's implications that the scheme is novel, important or secure, supports the derisive view of the author in the sub-thread above. Also check out the stylistic buffoonery on his site.
note that i am not affiliated with grc; my name is permuted :)
It would be interesting to know why Google didn't pursue it. Maybe a 20% project? https://plus.google.com/101935995649723391317/posts/P94xEz9D...
Another similar system http://corp.galois.com/blog/2011/1/5/quick-authentication-us...
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/14761/6...
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.
Future: bookmarklet / plugin / browser support that detects the code on the page.
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.
Whatever you use to unlock/authenticate to the device would be the other factor.
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.
(And no problem. If we were forced to comment using only precise terms, with no simplifications, comments would either be ridiculously long or nonexistent.)
Con: requires internet connectivity, unlike some 2-factor implementations
So, it seems feasible offline with online required only for convenience.
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...
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.
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?
As for losing the phone, he suggests a passphrase-like "local password" on "The user's view of the application" page [1].
Sure. People never get their phones stolen, never buy new phones, people never irreplaceably destroy their phones dropping them in a toilet.
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.
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.
I like!
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.
Note: the SSL certificate on the demo server has expired. I'm working on getting it renewed, but this is just a demo anyway.
- "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.
With 2^512 possible keys (~10^154) even if everyone on earth (~10^9 people) got a billion new IDs every second (~10^18 per person per year) it would be more than a hundred thousand billion billion billion billion billion years (~10^50 year) before there was an even chance of a single ID collision (~10^77 IDs => 50% chance of 1 collision). So I think we can safely assume there will not be a collision.
In fact it is almost always the case in cryptography that there will be some risk of failure but as long as that risk is very small the system is considered secure. This is way way way beyond the normal standards of security (say 10^30 or so).
Many of your other points are a matter of opinion. There will be always tradeoffs between usability and security. This system appears to offer similar or perhaps even improved usability to existing two-factor systems with enhanced security in some respects but similar weaknesses in other respects. I would love to hear the opinions of cryptographers and security experts.
[1] http://en.wikipedia.org/wiki/Birthday_attack#Mathematics
Truly random 512 bit keys will never repeat, ever, under any circumstances. Seriously, they won't.
You may consider this pedantism, but it's this pedantism and conservativeness that calls AES broken today.
If never is to have any meaning at all, it is in situations like this.
No, it doesn't. A one-time pad still needs a source of randomness, and a guarantee no reuse. How certain are you that you don't have a backdoored RNG, or initialization vector reuse?
Or, for a fully general argument, how certain are you that we're not living in a computer simulation, where the Dark Lords of the Matrix can just lookup their logs to see what random values were generated for your one-time pad? Or if we go to that extreme, how can you be absolutely certain of the truth of anything - including mathematics - if said Dark Lords could be messing with our brain and memories?
Or more mundanely, how about this: a flurry of cosmic rays strike the RAM containing the message and by random chance flip the same bits that were set in the on-time pad. Tada, message decrypted.
I'm pretty damn certain none of those hypotheticals are the are even remotely worth worrying about. I may even be more than P(1 - 2^-512) certain that they are false. But it's still merely a very high, finite probability. P(0) or P(1) don't exist - you can approach them, but you can't ever reach them.
Any idea, no matter how crazy or out of place with our understanding of the universe could happen, at least in principle. Therefore if we want “never” have a meaning at all, we need to set an cutoff point where we stop caring. Obviously an appropriate value depends on the situation, but in this case I'm pretty sure that an appropriate cutoff is somewhere up of P(2^-512).
Although, in some respects, I do get where they're coming from. New algorithms and computing paradigms develop that make the previous one broken. I'm just guessing here, but it maybe possible that probabilistic computers and awesome algorithms a few decades down the line are able to recover states of a CSPRNG by applying statistical techniques. Obviously, I'm way over my head here but this is a possibility.
If you say that the OP was talking about TRNGs then all bets are off. It could so happen that two consecutive 512-bits are exactly the same. The probability is extremely low (birthday low) but since it's a TRNG there's still a chance that it will happen.