
Clef Offers Two-Factor Authentication Without All the Codes - pixelcort
http://techcrunch.com/2015/02/19/clef-offers-two-factor-authentication-without-all-the-codes/
======
freehunter
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.

------
nicolasehrhardt
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.

~~~
csixty4
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.

~~~
e12e
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".

------
e12e
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?

~~~
harshreality
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).

~~~
e12e
> 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.

[1]
[http://en.wikipedia.org/wiki/QR_code](http://en.wikipedia.org/wiki/QR_code)

[2] [http://crypto.stackexchange.com/questions/3216/signatures-
rs...](http://crypto.stackexchange.com/questions/3216/signatures-rsa-compared-
to-ecdsa)

[t] [http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-
google...](http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-
authenticator.shtml)

------
stoshe
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.

~~~
stoshe
Found the Google product's name: Open Sesame

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...](http://www.webpronews.com/open-sesame-googles-newest-security-log-
in-uses-qr-codes-2012-01)

------
oostevo
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.

[1] [https://www.duosecurity.com/product/methods/duo-
mobile](https://www.duosecurity.com/product/methods/duo-mobile)

~~~
harshreality
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)

~~~
jessepollak
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.

~~~
harshreality
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?

------
mmastrac
Previous:
[https://news.ycombinator.com/item?id=7224882](https://news.ycombinator.com/item?id=7224882)

------
jarin
Is the vertical movement actually part of the authentication, or is it just a
fancy looking barcode?

------
niftylettuce
Simpler: [https://getprove.com](https://getprove.com)

~~~
hackerboos
Not free.

------
prawn
I was expecting the solution to involve humming a four note tune.

------
elsbree
I was impressed by how easy it was to integrate Clef into my existing auth
system- by far the best two-factor authentication system I've used.

------
michaelbuckbee
I've always through Clef was really neat, at the very least it is great to see
a company tackling security from a UX standpoint.

