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.