Clef Offers Two-Factor Authentication Without All the Codes
techcrunch.com
techcrunch.com
At least with Google Authenticator other people can write compatible applications for other platforms.
I think (pragmatically) phone's can be "something you have" -- but except for a pin/passphrase that actually unlocks the full-device encryption on the phone -- nothing you do with the phone to access a secret key can be considered a second-factor "something you know".
Last I heard iphones have a decent storage for secrets, in the sense that you can't get at them except by using the phone to bruteforce the pin (and get into the trusted storage/unlock the key). It's been a while -- maybe iphone 5/6 are better though. But I doubt it. Android devices in general have no such luxury -- on the other hand one can/should use a complex pass-phrase when enabling FDE, similar to other "soft" FDE-solutins, like cryptsetup for Linux. There's host of possible attack vectors, like subverting the BIOS/bootloader, getting at the juicy bits if the phone is booted up/the device decrypted, probably possible to do cold boot attacks etc...
At any rate, claiming that anything stored in an app is "secure" beyond the basic security of the phone -- is probably just wrong. That doesn't mean a pin is useless, it's just not really "two-factor".
1: Set up OTP as usual (pc/web-app shows qr code, scan code with phone. Server and phone now share a private secret for generating OTP tokens)
2: For login: phone displays QR-code, pc/web-app asks for image input (with 6-digit code fallback) -- user holds up phone to pc-camera.
I don't really see how Clef offers any benefit, except that you can't use standard OTP with Clef. Am I missing something?
Their offline mode seems like FIDO but with a bidirectional wave image / camera requirement to get around lack of a better data channel (like u2f-hid support that FIDO requires).
Probably not. Supporting traditional (T)OTP is more about interop than anything else (the back-end just gets a one-time code to check against a list/counter or against a time-derived token, checking for drift etc. Main point is you can keep your auth-stack as-is, and your shared totp-secret in the same place[t]).
You could probably do assymetric crypto fine with qr-codes[1] they pack a lot of data.
If an ECDSA signature is ~48 bytes[2] -- that's going to be hard to compact down to a reasonable fallback... maybe. If the idea is to use asymmetric crypto as a backing for OTP, I suppose you'd do something like signing TIME+salt, and transmit the signature and the salt. Unless there is some trick one can do with checking partial asymmetric signatures, I don't see how you could get away with sending less than SIG+salt, or ~50 bytes. That's way too long for typing in, as a usable fall-back.
It might actually involve less typing to generate a shared secret -- but that'd completely break the UX -- so it doesn't sound like a sane fall-back to me.
[1] http://en.wikipedia.org/wiki/QR_code
[2] http://crypto.stackexchange.com/questions/3216/signatures-rs...
[t] http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google...
Google used to have an authentication system that would display a QR code on the screen which you would use your phone to navigate to. That URL would then, assuming your phone was already authenticated to Google, log you in on the computer as well. I was trying to remember the name of the system, but can't come up with it.
The short version is that Google determined the system to be too insecure and vulnerable to exploit and canceled the system.
The site no longer exists, but some of the news about it at the time can still be found: http://www.webpronews.com/open-sesame-googles-newest-securit...
They offer a push authentication capability, so you only have to click "accept" or "deny" in the app on your phone. They've also got code generation and a hardware token as backups. In practice, I can usually authenticate through the phone in 2ish seconds.
Clef does look like an awfully nice user experience, though.
I don't want my ability to use a system conditioned on whether my phone can connect to the internet, or whether I have a laptop with internet connectivity and a camera that can take a picture of my phone's screen. TOTP 2-factor and FIDO* are better for that reason.
Clef sounds almost exactly like a software (totally app-based) FIDO implementation without a separate password other than the PIN you'd enter into the FIDO app. FIDO needs browser support, though; Clef can't do it that way, so it requires a data back-channel to Clef servers.
* (once it catches on... tokens exist, and Chrome/chromium 39 and above supports it, but MS has only announced it for Win10, FF hasn't implemented it yet, and hardly any major sites support it other than Google)
A lot of work has gone into the FIDO spec to make sure it can be used across a wide range of environments. I don't see the utility of buying into a proprietary 2-factor system that seems to be solving the same problem. If you added u2f-hid support to eliminate the hack of transmitting data via pictures and cameras, wouldn't your system behave exactly like FIDO?
Isn't the natural progression for a company like Duo or Clef to pivot to being a managed FIDO 2-factor service, for organizations that want central management of 2-factor auth without creating their own management system?
I grabbed an address from their website and asked if this email was legit or a phishing attempt and it took quite a long time to get a response. By that time, no one at the company had any patience left for Duo. You don't sell to enterprises by acting shady.