I used Clef to secure a personal blog that I run. Really nice, slick UI, and fun to show to people because it's so different. I had to uninstall it, though, when I had broken my iPhone and switched temporarily to an old Windows Phone I had laying around. I never reinstalled it, because an authentication method that relies on having a specific piece of expensive technology isn't all that attractive to me. Maybe it's great for someone who will always have an iPhone or Android phone, but in the last two years I've had five phones, and three of them were platforms that Clef doesn't support. This "iOS or Android" nonsense might work for games, but for any application I need to rely on for my workflow, it has to work anywhere. FirefoxOS might be the next hot thing, and if people switch to it, they're going to switch away from Clef.
At least with Google Authenticator other people can write compatible applications for other platforms.
If you remove the password, how is that a two factor?
The day you loose your phone/get robbed could lead to your worst nightmares. Definitely would never opt-in.
I loose my phone all the time (I know...), but I am pretty sure I am not the only one.
The factors are shifted to the phone. The Clef app on your phone is protected by a PIN (separate from your lock screen code) or TouchID on iOS. Each instance of the app is registered with Clef so you can revoke an individual device.
Yeah, well. "protected" by a PIN. You're implying that if someone gets hold of the phone/mirrors the storage, they can't get at the clef secret key because of the "pin". That's probably not true.
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".
Seems like this could be simplified to simply extend standard OTP (with the caveat of requiring a camera on the laptop, probably invalidating one of the use-cases of OTP: logging in to low-security accounts on a kiosk pc):
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?
Functionally that's what it sounds like they've done with their offline mode. They use "wave" style images instead of qr codes. They also use asymmetric crypto I think, like FIDO, but unlike OTP. It might not be feasible to offer a 6-digit code fallback, though, unless you can map RSA or ECDSA or whatever they're using into a problem with a 20-bit solution space without allowing offline brute forcing.
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).
> It might not be feasible to offer a 6-digit code fallback, though, unless you can map RSA or ECDSA or whatever they're using into a problem with a 20-bit solution space without allowing offline brute forcing.
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.
How is this different from the phone based 2-factor that Google once had for their own products? Honest question, not being sarcastic here.
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.
Similarly, I've been impressed by Duo's mobile applications.[1]
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.
Duo, Clef, or SMS 2-factor all have the same caveat: they require internet or SMS availability on one of your devices, not just the computer/device you're logging in on.
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)
Clef actually doesn't require internet on the secondary device. We just shipped offline mode a few weeks ago: it's not as seamless as the primary flow, but it works well and solves the problem. Turn on airplane mode, sync the wave and let me know what you think.
So in that mode it's a proprietary alternative to FIDO that requires a camera to image the phone's screen?
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?
With Duo, in addition to the online request acceptance, you can also get a code from the phone without being online, and type that into wherever to finish logging in.
I've got a bit of a sore spot when it comes to Duo Security. I was working at an enterprise a little less than a year ago when we got an email from Duo Security saying they had analyzed a password dump from the Adobe breech. They wanted to let us know that several accounts tied to our organization were contained in the dump and used that to try to sell their solution. It didn't help that their email addresses didn't have the same domain as their website, and the addresses they emailed us from didn't have the same domain as the address they asked us to respond to.
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.
Duo has been awesome. I hit my login screen, enter password, send notification and hit accept on my phone. Ridiculously easy. The only problem is when you phone battery is dead.
At least with Google Authenticator other people can write compatible applications for other platforms.