How 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.
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.
Well, 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.
It'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.
I 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 ;-)
It'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.
Right; 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.
Yeah, 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.)
Beyond 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...
2-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.
Well, 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.
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...
That'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.
drivebyacct2 - 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 (hint - the ban is completely unjustified)
Dan 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.
Interesting - 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.
> 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.
Not 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.
Sure, 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?
It's still an ad hominem - the merits of his argument should stand independent to who he is or his history on any topic.
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.
I disagree. He doesn't address the actual topic here at all. All he is doing is saying that Steve Gibson is a charlatan.
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.
It may not be as strong an argument as, say, going through the crypto with a fine-tooth comb and finding flaws. However, I'm not qualified to do that, and most of the people commenting here aren't, either. Even so, we might have to make a decision about going forward with the information we have.
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.
Actually 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.
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.
It is never fallacious to point out the historical unreliability of a source. It is doubly never fallacious to point out the unreliability of a source, on a given topic, when discussing a new claim, on that topic, from that source, because that information is relevant to how we approach and evaluate the new claim (i.e., claims from historically-unreliable sources should be subjected to greater initial scrutiny).
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...
There are a few types of ad hominem but they all involve using some property of a person that is only tangentially related. This note about how the majority of the security community sees Steve Gibson speaks directly to an assessment of his ability in this field.
Personally, even if the design is ok, I don't care to give this chucklehead any publicity. Maybe the blind squirrel found a nut (see what I did there? SQRL?) by getting a design right. Doesn't mean it's anything particularly clever, or that we should use it and give him something to base his incessant self-promotion on for the next 20 years.
Looks more like a simple character attack than anything. Steve is prolific, experimental, and has been around a while, so it's understandable he hasn't done everything right, but I haven't found any other instances where he is considered a "charlatan" by other security professionals.
Gibson is prone to hype and proclaiming that the sky is falling which is why I rarely listen to his show. However, a lot of these are nitpicks where he either gave the wrong meaning of an acronym or oversimplified something while trying to explain it.
I can't make him out to be a buzzword slinger. I've listened to quite a bit of his show (although admittedly very little from the past year or so) and he definitely demonstrates good knowledge. Listening to him talk, my impression is that he brings the security mindset[1] to the table, rare among snake-oil peddlers or charlatans.
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.
This 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.
The 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.
It seems like the basic idea isn't unique. I was thinking of something similar a while back and found https://tiqr.org while looking for similar ideas.
Thinking 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?
With 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].
A 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.
I 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.
A 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.
I 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.
This looks like a much less polished version of Clef (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).
That'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.
One 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?)
Nothing 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.
As a counterpoint: It's far more likely i might be mugged for the easy cash scored by a phone that has a 500€ market price, than to have my desktop stolen. ;)
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.)
Right now, sites need to explicitly integrate with us. We've thought a lot about creating something that manages passwords to bridge the gap. We've actually been working on this with some community members (Joe is here somewhere) and are hoping to roll something out in the next few weeks.
Sorry for not addressing 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.
Thanks for the answers. I'll be looking forward to see it hit hackernews.† :)
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.
Mithaldu, just as a reference, I'm the guy working with Clef on enabling Clef on more sites.. We've got a pretty cool system, and it's getting dang close to release. Hopefully I'll have it finished soon!
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.
Possession of the device and typing a PIN into the _same_ device does not qualify as 2FA.
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.
I am pretty sure that possesion of device and typing PIN into the same device qualifies as 2FA. A spy that watches you type your PIN can't log in without your device. At the same time, a thief that steals your device, but doesn't know your PIN, also can't log in. You need both; hence TWO FACTOR AUTHENTICATION.
The casual thief case is trivial. Surely, clef's goal includes protection against a somewhat more sophisticated adversary who is targeting you, specifically.
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.
But 2FA doesn't protect you from even a single compromised device. If the computer you use to access the service is compromised, an attacker can simply intercept your next login attempt. The only difference is that in the case of CLEF the vulnerable part is your mobile, not your laptop.
How does this work for mobile sites? This looks great for using your phone to login on the desktop, but how do you use your phone to login on the phone? I'd love to push this where I work, but I don't think it will fly if it doesn't work on the mobile site.
When you click the button, you'll just be redirected to the app where you can confirm or deny the login. If you confirm, you'll be redirected back and logged in.
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.
Indeed, and the polish is what makes Clef awesome and a pleasure to use. Their Wordpress plugin is a great way to drive adoption, but I find myself wishing more sites supported it.
I have found 1Password to be pretty hellish, and I don't even consider not using a password manager an option anymore. So clef and SQRL sound great to me.
Fair enough; although, in our experience users have enjoyed the flow much more than passwords. I'd encourage you to give it a shot and let me know if it's as unbearable as it seems to you.
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.
This is functionally the same thing as 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.
Here'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)
> 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.
Do you enter the identity password each time you scan a qr code? If not, it's still one factor. Even if you can enter it each time you scan, it's still only on the phone, making it the same if not less secure than doing it all on your desktop.
The user is vulnerable, not only to "malware" but also to the phone vendor (and anyone the vendor enables, notably government). The degree of control one can attain over a phone or tablet is much less than on a general-purpose PC, and the latter is hard enough to relatively secure. Smartphones are captive, remote-controllable devices and as such are not trustworthy for secure communications or any important secrets.
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.
I 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.
137 comments
[ 2.5 ms ] story [ 180 ms ] threadI 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.
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.)
[1] https://www.grc.com/sqrl/userview.htm
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.
[1] http://twit.tv/sn
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.
So then they pulled it, told us something better was coming and nearly two years later, nothing.
(https://news.ycombinator.com/item?id=5974604)
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.
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?
> 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.
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://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...
http://en.wikipedia.org/wiki/Argument_from_fallacy
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_......
Sure. People never get their phones stolen, never buy new phones, people never irreplaceably destroy their phones dropping them in a toilet.
[1] https://www.grc.com/sqrl/userview.htm
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
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...
Future: bookmarklet / plugin / browser support that detects the code on the page.
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.
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.
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 :)
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.