Clef – stop using passwords | Hacker News Reader

Clef – stop using passwords

getclef.com

114 pointscharlieirish96 comments

So for this to work, the website has to be on board, the user has to be on board, the user has to have their phone present, the user's phone has to be in working order (camera working, network working), the clef server has to be running correctly, and the software has to be working correctly on [the user's phone, the website's frontend, the website's backend, and the Clef servers].

Current process: click login box, type, tab, type, enter. With clef: click cleff box, find phone, unlock phone, launch clef app, hold in front of screen, wait.

All of this to create an "advantage" of not having to remember a password at the cost of probably 15-30 seconds longer login time and a login process with more brittleness, as many steps, and more complicated steps.

Is there a big advantage I'm missing, because right now this looks worse in almost every way and dubiously better in only one.

I say dubious because I wouldn't trust the system to work, so id still memorize backup passwords. But some people have higher trust and thus would get the benefit.

The animation is cool though.

There are a few advantages you're not mentioning: 1) This is two factor authentication. I don't trust any of my really "essential" accounts like GMail or Coinbase without two factor. And all of the problems you mentioned around needing your phone are common to nearly all two-factor auth solutions.

2) More secure password. You won't be susceptible to many brute-force based hacking methods because your password won't be in any rainbow tables or anything like that.

How is this two factor? As near as I can tell, it replaces your password (something you know) with your phone (something you have). It doesn't add a second factor to the auth.

Two factor auth is defined as something you know plus something you have.

Two-step verification (also known as two-factor authentication) is a process involving two stages to verify the identity of an entity trying to access services in a computer or in a network. This is a special case of a multi-factor authentication which involves the presentation of two or more of the three authentication factors: a knowledge factor, a possession factor, and an inherence factor.

Their point was, there's only one factor here: something you have. There's no password you give the site. So it's one factor. It is probably significantly safer than just a password, since nigerian hackers can't steal your phone from a huge poorly secured database.... but it's still just one factor.

This is not two factor authentication, since it eliminates one of the factors (the password). Gmail's doesn't, so that is two factor auth.

Clef app has a PIN. And my phone has a lock screen password.

No, because you're not authenticating to the service.

Think about what would happen if your phone gets owned by some malware that escalates to root. It can simply log the PIN, extract the key and then login as it wishes. That's because the phone is the single factor for the service.

Compare that with the auth against, say, Gmail, where even if a malware were to own the Authenticator, it still couldn't login as you, since your password goes directly to the service.

I finally installed Google Authenticator on my phone yesterday because Digital Ocean utilizes it. It's great. Like RSA stuff, only more convenient. And hopefully given the response of Google's security people to NSA activity, more secure than the RSA stuff.

This thing basically looks like a more automated version of Google Authenticator. Cool, but meh, would it really change my life?

But maybe it would make a difference for the same market that feels like the iPhone 5s's fingerprint scanner is way more convenient than previous security mechanisms on the iPhone and so can never go back. I dunno.

Google's Authenticator 2FA system is based on an open standard [1], and can even be implemented on your own/other web sites. Given the open nature of the standard, that can be considered an additional safeguard against NSA exposure.

[1] http://en.wikipedia.org/wiki/Google_Authenticator

May I suggest you try the Authy[1] app for your phone. Its much prettier than GA, has a PIN screen lock, and can save your encrypted credentials in case you lose your phone. Plus, if you run OS X it will sync to your computer's clipboard via Bluetooth.

[1] https://www.authy.com/

While this is cool, I don't think I can replace GA with this because GA is the one implemented by the services I use, yeah? I can only use this for services that implement this.

Authy's app works with Google Authenticator-compatible sites. Authy also has its own two-factor system, but you're not required to use it.

> all of the problems you mentioned around needing your phone are common to nearly all two-factor auth solutions.

Not true. From his list of problems, TOTP does not require the Clef servers (or any third-party server), nor does it require your phone camera or (more importantly) phone networking to be working.

And to make the comparison fair, you have to realize that this is not two-factor. There's only one factor (something you have) since there isn't a password requirement.

This is wrong though because unless you have the same password for everything (you shouldn't) the process isn't the single serving:

click login box, type, tab, type, enter

It is moreso:

click login box, type one of passwords 1-10, tab, type, enter

Which assumes you remember each one. It's an even better use case scenario if you are the guy with only one password for everything.

I would think something like lastpass is an even better workflow however.

1. click login button 2. there is no step 2

Lastpass used to work like that for me. Now it causes me about as much hassle as it saves me. It does not do a wonderful job of handling multiple accounts on single sites; I frequently find multiple entries in the vault for single accounts, only one of which has the correct password (and usually the username is missing), and there are a number of sites whose presentation seems to baffle Lastpass, either in the login screen or in form-filling.

Also, Lastpass doesn't seem to offer to do as much for me anymore. Maybe I screwed something up in my config, but I don't see an AutoLogin option anymore.

So I'm just about ready to abandon Lastpass if anything else comes along that gives me a user experience like Lastpass used to give me. I don't know whether Clef is that service, but I'm at least glad that someone is exploring the space.

+1 for LastPass. Saves a bunch of time. They're pretty damn persistent about doing security the right way -- they don't have the key to open your data.

Except that's a bandaid over existing solutions. It's hard to imagine in 50 years we'll still require people to remember both a user identifier plus a password.

It's a tough problem. Human memories are fallible, yet it's with you always. Passwords can be given to others, which can be convenient in many situations (something bio recognition can't do). Bio markers like fingerprints are left everywhere as CCC has demonstrated, or the markers themselves can change such as with Macular degeneration in eyes. Phones can be stolen or run out of battery, physical key cards lost, and centralized systems like RSA's SecurID hacked.

In a lot of ways the banks have it done best, with combining a replaceable physical object (loanable) with a short PIN (sharable and more memorable), and then throwing fraud detection on top of it. It's the last piece that's the best and also the least available for others to do easily.

The problem would be better addressed by having a turn-key solution that any company can easily plug into their code to detect fraud attempts on short passwords. Big hole waiting for a startup to fill...

Plus the notion of "which of my ten passwords did I use for 'xyz.com?", you end up exposing your other nine passwords to 'xyz.com. Not as bad as using the same password everywhere, but still. I wouldn't want to accidentally give my bank password to, say, a crappy online forum.

BTW, what about the security implication of this password-test-runs? Users are essentially giving their "other" passwords to the site, right?

Obviously a benevolent site will NOT save/process those failed passwords, it may even take care to have them NOT stored in any logs...

An malevolent site on the other hand may even trick you into providing it some of your other passwords to it...

...cache invalidation, naming things and secure authentication for a broad public

I don't think it's any more accurate to say the average case is having to cycle through ten passwords to login to a site. Generally, I remember my passwords for most sites, and for the few I don't get right on the first try, I'm usually able to get in by the second. And yes, I have more than two passwords I use.

> the user's phone has to be in working order (camera working, network working)

battery not dead...

Just about all the widely public 2 factor schemes out there leverage cell phones via SMS or another route, they all require your device to be some battery life.

I bought a yubikey, but hardly any web services support it.

Actually, any website that supports Google 2FA also happens to support your Yubikey Neo, assuming you have a Neo.

Step 1: Install the Yubico Authenticator from the Play Store.

Step 2: Install the OATH applet. Linux instructions are at http://forum.yubico.com/viewtopic.php?f=26&t=1159, but there are OS X instructions kicking around on the forums as well.

Step 3: Wherever you would normally use Google Authenticator, use the Yubico Authenticator instead.

You now have proper two-factor authentication.

EDIT: Wrong link...

Damn. I bought the standard.

Well, sit tight. There's a new version of the Neo that supports U2F (https://sites.google.com/site/oauthgoog/gnubby) coming out Real Soon Now (https://www.yubico.com/products/yubikey-hardware/yubikey-neo...) -- sometime in 2014 is all I've heard.

None of the 2FA services that I use require me to use an actual phone. The phone number that I associate with 2FA services is set up to forward SMS messages to an email account that is dedicated to receiving only SMS messages from 2FA services.

How is that two factor any more? You've broken the security model. You now have only a knowledge factor, no possession factor.

The whole point of two-factor authentication is to make it so you need two things of two different types. You reduced this problem to having two passwords (two things of the same type).

Do you mean there is any significant difference between an email and SMS accounts?

I think that depends on the adversary. Against the NSA there might not be a major difference (depending on your email provider), but SMS is probably more secure in the typical case, as it is much more common for your run of the mill script kiddie/phisher/etc to get access to someone's email than their phone.

At least some mobile operators have "SMS archive" option, that can be enabled and accessible from self-service site. It requires some time to set up, but attacker with sufficient time, knowledge and patience may pull the attack relatively easily. No need for NSA-grade adversary.

(Even worse, until relatively recently they had used numeric passwords (those had to be set from a phone, using DTMF tone dial). This had changed only 3 or maybe 4 years ago. Wonder whenever that change was 2FA-related. :) )

So I'm uncertain whenever SMS is more secure.

But then you get added security. This isn't two factor, this is one factor.

You have to enter a 4 digit PIN number into the app. It's still two factor, since you have to auth to the app to get the one time pass.

Also, if you want to log into the site on your phone, you need a second phone.

Pretty sure they have an app to solve that.

Pretty much, yeah; this is condemned to fail and they should pivot ASAP.

Beats the heck out of time-based algorithms that generate a code on a fob. Obviously not usable everywhere, but definitely a solid option.

Yes, yes, except this allows you to log in from an untrusted computer.

How? An untrusted computer can just steal your session token.

They keep saying this is 2-factor authentication, but without the first factor (something you know e.g. a password) and going straight to the second factor (something you have e.g. your smartphone) they actually only provide a single factor for authentication.

This is of course less secure than true 2-factor authentication, and the web site is misleading in its wording.

> They keep saying this is 2-factor authentication, but without the first factor (something you know e.g. a password)

I always wonder about this even when there is a password. For most services, a phone compromise would be a total compromise. I rarely get prompted for a password on my phone (nor do I enjoy typing one when I'm trying to do something quickly.)

Well if you choose two-factor by sending the code to your SMS and your device is lost it is certainly doom. Just as if you lose your laptop there is a great chance someone with enough patient and skill can/may hack into an encrypted disk/brute force the login.

To be fair if your phone is locked with a pin then we're still at least roughly in "something you have and something you know" territory.

Very roughly. When you put in your phone lock pin, you are not authenticating with the website. So roughly, it's not.

I dont see how that matters. You still need a password + one file (on the phone). SSH keys with passphrase are two factors as well in my book. In fact, I would say that not having to transmit the weakest part (the mnemonic password/pin) over the wire is a plus.

I dont see how that matters.

Please tell that to anyone thinking of hiring you for security.

I asked this exact question to the team on Twitter a few days ago when I first heard about this. Their response[1] was that you need a PIN to unlock the app.

[1] https://twitter.com/getclef/status/431095300619390976

No matter how well protected the phone or app is, the receiving service still only gets one factor of authentication.

PIN is short (usually). Which means if somebody gets their hands on your phone, they need to only guess about 13 bits of information (for 4-digit PIN) to get access to every site you ever logged in with this phone. That provided they actually use the PIN to encrypt the data, not just to check access to it, in which case once somebody gets their hands on the phone, it's game over.

I am glad that people are exploring this space, but Clef is not the solution, IMHO.

LastPass currently fulfills similar requirements for me and actually speeds up logging into the site. Is it perfect? Absolutely not. But the UI works pretty well.

I'd like to see it improved by starting to support public/private keys. The idea that I can log into a site using my private key means that when I simply get one <input type="identity"> and then the browser or a plugin like LastPass provides the UI to fill it in. This would actually be much faster than passwords: you see the input, select an identity from a dropdown or autocomplete you'd like to use, and click "Go".

Seems a little similar to Steve Gibson's SQRL, I think:

https://www.youtube.com/watch?v=ZrQboo3pA10

http://sqrl.pl/guide/

https://www.grc.com/sqrl/sqrl.htm

He said in his recent Security Now podcast that he had some breakthroughs in terms of how SQRL will work, so it will probably change quite a bit from how it's presented at those two links. He also said his solution is better than what the FIDO Alliance is trying to achieve, but we'll see when it's ready if true (it does sound like the FIDO Alliance has created a few adoption problems for themselves with the licensing and whatnot, though).

This immediately struck me as a ripoff of SQRL. I don't think there are any meaningful improvements in the linked solution.

Actually, Clef was already developed and launched before SQRL was even announced. SQRL does, however, have many benefits over Clef, though the typical user interaction is similar.

That one doesn't require a smartphone, I believe.

Sorry for the deliberately stupid question but: What if I need to login somewhere on my phone?

The image that you're supposed to scan will also be a link with some custom procol (like clef://...), which then gets handled by the Clef app.

I'm glad there's movement in this space. It's desperately needed. Password managers are great but difficult to extend to all use-cases. When a generated password cannot be easily copy-pasted, the whole system feels unwieldy.

But Clef doesn't seem to solve anything in that respect. It solves some of the same problems that password managers do but with extra environmental requirements.

I can see the Clef mechanism being useful for 2-factor authentification. But I'm unenthused with (and wary of) its current instantiation as a login skeleton key. If I were Clef, I'd set my sights lower and rebrand as a drop-in 2-factor auth system to be optionally enabled by users.

> Clef puts military grade cryptography in the hands of every user

This kind of line is deceptive for 99% of end-users and turns off the 1% who might be helpful as developers.

Where do they say military grade? That's always a bit of a red flag for me.

This is actually something we thought we removed everywhere. I just grep'd our repo, found one lingering instance, and committed it out (will deploy when the traffic goes down). We understand it's deceptive and recognize the need to communicate to our users why Clef is more secure than usernames and passwords in a straightforward way.

Here: https://getclef.com/developer/

Also: https://www.schneier.com/crypto-gram-9902.html#snakeoil

OMG this will make moving around the internet and logging into 100's of sites so much easier and faster... oh wait. find app, click app, wait for app to launch, scan screen..., scan screen again...,(damn it!) scan screen again holding further back and making sure it has focus, got it!. whew. that was so cool and easy. I'm so glad my Wordpress admin page has this level of security because what I say is THAT important.

Hardware integration is needed for this and mobile payments to be less frustrating and fast. Apple/Google/Samsung are the ones in control.

Why not just have browser support for SRP as a standard type of form request or TLS-SRP? It's fairly well known crypto and doesn't require a 3rd party service to be active or access to a smart phone with an active network connection.

SRP doesn't solve the problem with having to remember (or store) good unique passwords for each site. It does help with the authenticating password over insecure connection but SSL solves that for most sites. It doesn't solve the problem of securely storing passwords; the value that is stored can be brute forced to get password and is equivalent to cleartext password for any SRP using site.

> It does help with the authenticating password over insecure connection

I'm not sure you understand what SRP is; it's built to be used over insecure connections.

> It doesn't solve the problem of securely storing passwords; the value that is stored can be brute forced to get password and is equivalent to cleartext password for any SRP using site.

I don't think you understand what SRP is; if you could do this, then public key crypto has a much larger problem then passwords and you should be worried about TLS as well.

Why not just have browser support for client X.509 certificates?

Oh, wait, we have one. It's just that UIs are horrible because noone ever cared about that part (because nobody uses it, because UI is horrible).

Good thought. I believe SRP is patent-encumbered.

Actually, it is just the opposite. According to wikipedia, SRP was carefully designed to avoid any current patents, and according to this stanford page[1], it is available commercially and non-commercially under a royalty-free license, along with a BSD-ish-licensed Open Source implementation.

[1] http://srp.stanford.edu/whatisit.html

Would be better if you cut out the centralised authority, take a look at SQRL https://www.grc.com/sqrl/sqrl.htm

What about MITM, if I show image of client 1 on client 2?

I don't know if clef does this, but for SQRL (similar, but uses QR codes, is open source, and doesn't rely on a 3rd party), it relies on the fact that the website URL will be embedded in the QR code (along with a signature) and that the app will show that URL to the user for them to confirm.

This isn't strictly stronger than standard password MITM (phishing), because unattentive uesrs could still just click through without checking the URL or the https status. IMO it is still an improvement because it makes that step explicit, and gives us a chance to put some nicer UI and programmatic checks around it (warning about weird unicode tricks, high similarity to previously used domain names, ...).

Also, both Clef and SQRL use public-private key authentication, so if a bad guy does successfully MITM someone, they only get one session to do bad stuff as opposed to knowing the password and being able to re-authenticate wherever. Obviously this is pretty poor security (it only takes one login to empty someone's bank account...) but for some applications it might be significant - notably for websites require you to re-authenticate to take destructive action.

Also XSRF with QR code meant to log in to site 1 shown to client on site 2.

So one use case, where any phone based solutions are a bit off is: when you're travelling.

1. Phone in roaming and no network

2. Battery dying out.

It locks you out of using a bunch of services.

I had a really bad time when my flight to NYC got redirected to Tashkent and was stuck for 2 days. I couldn't logon to any services. My phone wasn't working, so i did not receive sms notifications i had setup. GMail(and FB and a bunch of others) all thought my account was being hacked and wanted me to verify via my phone or email. So i was stuck in a foreign country, with phone roaming not working, and no way to contact and let people know that where i was.

So i've definitely stopped using any SMS phone verification, i'm still hesitant to use Google Authenticator(although i've shifted most of the accounts to it), because my battery tends to die at odd times while traveling.

Doesn't Google Authenticator provide you with a list of one-time use codes you can print out and carry with you for just those types of situations?

Google does, when setting up 2FA. That's independent of using the app for other services.

Ah, it's unfortunate Google doesn't authenticator as an open service then.

Yeah. I was traveling, took a train, and left my phone in the car parked at the train station.

Trusting a mobile app with my passwords? Sure I may as well email all the passwords to the NSA instead

It's good to see advancement on the ux side of 2fa. Many of the other players in this space provide such a cognitive burden that scares average users back to passwords. I'm excited to see where this one goes.

I am so scared moving all my "right" to my phone. If my phone is stolen, that guy can browser my visiting sites history, and then try to use clef to login, payment...

You could still say this is 2-factor, I know my phone PIN, and I have my phone. It's interesting, yet not for me.

I'd rather keep with the SMS PIN's as part of my two-factor auth, no third party app required, no lost private keys.

Most people who jump on the 2-factor band-wagon care more about security then speedy access. They are willing to carry an extra device ( smartphone, smart card, USB key, etc... )

Anything that requires the user to pull out the smartphone and launch an app to authenticate is bound to fail. There's no way around it.

> There's no way around it.

That's the idea.

Drat, he's using clef! Oh well. Hit him over the head with a cro-bar and take his phone.

That's really cynical. This is as good as saying, put someone under sedatives to get them to reveal their password.

Security professionals have always distinguished three major potential factors for authentication:

- something you know

- something you have

- something you are (e.g. fingerprint / retina scans)

Part of the reason passwords have stuck around so long is that accurate and convenient enough biomarker device have been prohibitively expensive, and physical artifacts can be lost or stolen.

You can't put someone under sedatives to get them to reveal their password. To attack a password* you must coerce or trick a human brain into revealing it.

*Assuming various diceware-style caveats. Also, writing the password down and putting it anywhere other than a safety deposit box puts it back in the "something you have" category.

Interesting, but I couldn't find the answers to some questions on the site:

1. How much does it cost for the website / web application owner? 2. How much does it cost for the end user? 3. If nothing for either, how does Clef make money out of this?

For 1. Go here: https://getclef.com/developer/ it's in the middle of the page "Completely Free"

For 2. The App was free and I was able to use it free.

For 3. No idea :)

Wasn't there news recently about popular games picking up stuff from the phone that they are not supposed to?

If I keep my passwords / certs on my phone, anything that hacks my phone gets access to those, no?

Very similar app only with QR codes - http://capturein.com/

Do I understand correctly that this is just plain old client certificates with nice wavy picture on top of it?

How do you log in from the web page on your phone?

Yeah, I'll just type my password, thanks.

So, basically, I should replace something that exists inside my head, in an immaterial form, with something physical that can be easily stolen?!

Reply on news.ycombinator.com