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.
Con: requires internet connectivity, unlike some 2-factor implementations
So, it seems feasible offline with online required only for convenience.
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.
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?)
> 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.
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 :)
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.
- "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.
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.
Sure. People never get their phones stolen, never buy new phones, people never irreplaceably destroy their phones dropping them in a toilet.
As for losing the phone, he suggests a passphrase-like "local password" on "The user's view of the application" page [1].
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.
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...
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?
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.
Note: the SSL certificate on the demo server has expired. I'm working on getting it renewed, but this is just a demo anyway.
