Hacker News new | comments | show | ask | jobs | submit login
Show HN: Solving a very old problem — passwords (clef.io)
45 points by brennenHN 1551 days ago | hide | past | web | 82 comments | favorite



While this may be better for some people, I find it hardly convenient that I have to have my phone with me everywhere I go in order to use this system (rather than having my password in memory). On top of that, for people who are like my wife who have a knack for letting their phone die, this isn't an answer either. Then you get people like me, who have a Windows 8 phone and there doesn't seem to be any support for this coming soon. I checked one of the sites and it looks like you sign up with Clef which means there may not be any option to set passwords.

If you want a separate device for passwords, then I recommend using a Yubikey (https://www.yubico.com/products/yubikey-hardware/yubikey/). You can set a long string in the memory of the yubikey as the base password and then add the site name afterwards. If you make your base password "2435ulkahsgfoiasjeoi25095iuasdfaq3uinwetpq3gtlknfoi465098aydsfaoidsaf" then for logging into facebook you can use "2435ulkahsgfoiasjeoi25095iuasdfaq3uinwetpq3gtlknfoi465098aydsfaoidsaffacebook" and gmail could be "2435ulkahsgfoiasjeoi25095iuasdfaq3uinwetpq3gtlknfoi465098aydsfaoidsafgmail" etc. That way you have a password that is strong and easy to remember. The caveat to this, of course, is that it wouldn't work on mobile and if you lose your yubikey you would have to reset all of your passwords.


If you make your base password "[X]" then for logging into facebook you can use "[X]facebook" and gmail could be "[X]gmail" etc.

If I did this, I would give Paul Graham access to my GMail, Facebook, and online banking accounts -- they'd all be trivially derivable from my HN password, which he has (in principle).

No thanks.


To be fair, most people already do this anyways by using passwords multiple times. There are also two memory banks in a yubikey so you can set two different keys and alternate them using the schema I put forth above. On top of that, you don't need to use the site name, it is up to you what to chose, you can use something incredibly simple for each site and a simple password turns into a not so simple password.


To be fair, most people already do this anyways by using passwords multiple times.

At least they have no illusion of security. The scheme you showed provides lots of illusion, and zero security.

This matters because, for the same effort, users can get much stronger security, even a cryptographic guarantee of password independence. (Leaked site passwords yield zero information about other site passwords, even if they're derived from the same root). But they will not seek out these solutions if they are mislead into using broken schemes instead.

There are also two memory banks in a yubikey so you can set two different keys and alternate them using the schema I put forth above.

That's still terrible.


Negatory on this approach... one of the good uses for the Yubikey is TOTP[1][2] -- and TOTP must not share any key material across sites, rather, each site has its own seed.

[1] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al... [2] http://zetetic.net/software-onetime

Disclaimer: my employer makes OneTime.


Our goal is to get rid of passwords entirely. It is becoming more and more obvious that our memories are no match for raw computational power and clever social engineering, and that we need to be securing our identities with a much better mechanism.

With the passwords you're talking about, a malicious site would gain access to all of your accounts as soon as you created an account with them, which is one of the major problems with password reuse today.

As to Windows Phone support, it is definitely behind Android on our priority list, but it's something we are working on and planning on releasing as soon as possible.


If this works anything like the QR Code login that Google did a while back[1], you aren't replacing passwords, you're just hiding them (scan code containing target site info, send login request with some device identifier from app to Clef servers, perform OAuth OOB on the phone, once authorized, send user credentials to browser via polling JS or whatnot -- in this scenario, the device identifier from the app is your username+password). Worse yet, you're shifting all the login credentials to the mobile device, reducing 2FA to 1FA, with the single factor being the phone. If the phone is compromised, then the credentials are compromised, and this is a HUGE concern, since it's much easier to pick up a phone and walk off with it than it is to pick up a whole computer and walk off with it. The whole point of 2FA is that you have two physically disconnected pieces of input required to log in (user+password on the computer, TOTP code from a mobile device), so compromising one or the other doesn't mean a compromise of the given account.

I get and like the concept, but the marketing copy of "replacing passwords" and "bringing 2FA" to everyone seems ill-conceived.

[1] http://www.zdnet.com/blog/igeneration/googles-qr-code-log-in...


We do not use usernames or passwords at all. A session key is passed in the QR code. An asymmetric key pair is generated on the phone when you create an account, and the private key never leaves the phone. When you scan in the session key, the phone creates a signature using the private key which can be tested using the public key stored on the server.

As to the question of two-factor authentication. The first factor is ownership of the device, the second is knowledge of the PIN, which are two different and very real factors.

We really are replacing passwords and using two factor authentication, it's not just marketing.


First off, I want to commend you guys for taking on the problem. It's an extremely hard one, and I don't intend to be disparaging. Passwords are an incredibly difficult problem to solve, and trying to solve it takes gumption. I love getting individual websites out of the authentication game; delegated auth is a much better solution when it works right, IMO.

That said, what makes this quantitatively different from just using challenge-response authentication directly in the browser via a browser extension? Private keys may be password ("PIN") protected, and must be possessed by the authenticating user. In both cases, any compromise of the private key means you're owned.

Exploits like the Defcon "charging station" proof-of-concept and the recently-discussed Galaxy S3 DMA hole should make people extremely wary of putting all their authentication eggs in their mobile phone's basket. People will plug anything into their charging-port-that-also-transmits-data if it gives them enough juice to get throughout the day; this is a MASSIVE social engineering problem waiting to happen if something like Clef were to become commonplace.

This solves at least some of the problems of passwords (too short, often re-used), but comes with new ones (4-digit PINs are hilariously easy to crack, and can often be guessed manually if a touchscreen is involved; private key theft via malware leaves you in big trouble and you may never know it happened), and I worry that marketing it as a solution to all your password woes is a bit ambitious.


Keeping it on the phone means that we don't need to re-generate a new one or transmit your old one when you change computers.

You're absolutely right that keeping the data safe on the phone is an important challenge and it's something we're working hard on. PIN-based encryption is the solution for now, but an invisible attack could be dangerous (though the attack's you mention through the USB key require a rooted phone with permissions allowed, which is not common- privilege escalation attacks are one vector which we still have to work against)

We think what we have right now is a big improvement over the status quo, and that we still have a lot of room to keep getting better. Thanks for the feedback.


"With the passwords you're talking about, a malicious site would gain access to all of your accounts as soon as you created an account with them, which is one of the major problems with password reuse today."

First they would need to know the scheme. Second, one wouldn't haven't to follow that schema at all, you could use something simple and easy to remember for each site. Also, as I don't know the implementation behind this, but couldn't a malicious site do the same with clef with a man in the middle attack (as stated elsewhere in the comments)?

Another question: how would mobile browsing work? If I wanted to log into one of these sites on my mobile device, how would I do that?


This is a feature which will be out with our next release. When we detect the visit from a smartphone, we change the QR to a button, and when it is pressed we redirect you through the app, where you verify your PIN, then redirect you back to your browser where you are logged in.


Pretty spiffy. Good luck with your product!


Clef preaches two-factor authentication... but I'm pretty sure that's not what it is, unless they skipped showing something in the video.

The video only shows one factor of authentication. There's no password involved (which is normally the first factor).


It's a quick shot in the video, but part of opening the app is unlocking it with a PIN, which is the second factor. We know that a PIN will not stop a determined attacker for long, but since we make it possible to remotely deactivate a lost or stolen phone, it only needs to slow them down long enough for you to report it.


Oh that was part of the app? I thought that was just the iphone lock screen.

"We know that a PIN will not stop a determined attacker for long, but since we make it possible to remotely deactivate a lost or stolen phone, it only needs to slow them down long enough for you to report it."

And how would one be able to do this? Would they need a password? (Genuine question, not trying to be an ass)


Haha, I definitely don't take that as being an ass, it's an important question and it's part of an area that we're trying to improve.

We have a section of our website clef.io/lost where you go when you lose a phone. It asks for your email and PIN, then sends an email to you confirming the deactivation. If you click on the link in your email, the phone is immediately deactivated. If you open the app and enter your PIN, the deactivation is canceled. We want to make sure that an attacker has a hard time deactivating your account, but that you are able to quickly deactivate it when you need to.

In the long run, we do not want to rely on email, and so we will need to move to a paradigm of trusted computers or other methods of valid-user-identification.


Eh... I guess..

If you look at it that way with Google I'm using Three-Factor. I just.. a PIN doesn't seem like much of a factor, and is a drop in security from a password.


What do you mean, "three factor"? The factors are something you have (telephone), something you know (secret or password), and something you are (biometric). Google isn't allowing you to use biometrics like your fingerprint to log into your account; thus, you aren't using three-factor authentication.


Is the app's data on the phone encrypted using the PIN? If the phone is found by an attacker which can access its memory, will bruteforcing the PIN slow them down long enough?


On the iPhone, all of the data on the phone is hardware encrypted using the device keychain. The Android app does use PBKDF2-derived PIN-based encryption to store the data. A rooted device would be cracked more quickly than an unrooted one, but the brute forcing process is quite slow because the hashing is iterated many times.


  I actually think that's important to note. I personally was less interested when I thought it was 1 factor - but 2fa makes this much more interesting.


This feels somewhat MitM-able. Say I want to get access to your account on site Foo. I create a web site and entice you to log in on it using Clef. However when you initiate the flow I don't create a Clef code normally, but I replace it with a code for site Foo. Voila, my authentication to site Foo completes, and then given this I can pretend that you successfully authenticated to my site too (or error out and ask you to try again).


Good point! There is still a phishing vector of attack that we haven't solved in this release (you call it MitM, but really it's just advanced spear-phishing). We're working on several ways to solve this problem using geolocation and on-phone-login confirmations for higher-security sites, and those will be released soon.

Phishing has always been a problem with passwords, and the fact that we are still vulnerable to it is something we take very seriously. Users are, however, protected from many other forms of attack and the phishing vector is less profitable because it is so hard to do in a distributed way.


The biggest threat to this is that it's a 4 digit code to unlocked on the phone. A stolen phone would allow access to everything. Figuring out that 4 digit code is super easy from fingerprints.

To make it more secure it should be two factor. Users enters code, scan and then the phone gives him a unique to enter.


Even in the best case, knowing what the four digits are, there are 24 possible options. We rate limit the PIN to 3 wrong attempts per day, so an attacker would need 8 days to be certain to gain access to an account. It is easy to remotely deactivate the phone from a computer, so the user's accounts will be protected.

That said, this is an area we want to make stronger. Using facial recognition and other, more secure, methods of user identification are on our roadmap as important improvements.


Giving a facial imprint is very risky for the user. I think it's wrong to add this to the system and force users to give this information.

Good luck though


If I want to prevent you from accessing your account for at least 24 hours, couldn't I just try to log in as you and intentionally enter an incorrect PIN thrice?

Am I misunderstanding something?


Yes, you have to have the phone, but this is still possible.


Ah, OK. Better than a remote attack for sure.


Nope it is not solving that old password problem. It has created a freshly minted chicken and egg problem. http://www.joelonsoftware.com/articles/fog0000000037.html

If you want to solve the password problem just invent a simple mixed mnemonic/hashing solution that will allow people to derive passwords for different sites with ease but are hard to reverse.

Also how can I log into any site when my iPhone battery is dead?


The edge cases of dead phones and unshared internet (like on a plane) are something we're working on right now. We want to find a good second-string form of authentication when your phone is unavailable, and we have several directions we want to take this, but we've dedicated our initial development to making sure the primary form works really well.


This application needs to be something that runs on an open source ti-86 equivalent piece of hardware with no network connections and a battery life of forever instead of an iphone application, and then it will actually be successful. Until then, anyone smart enough to actually give a shit isn't going to be particularly interested.

People would certainly be more inclined to trust Microsoft, Apple, or Google with this sort of task than Joe Startup, and they haven't yet. Therefore, while this is a valid need, and really a very big market opportunity, I don't buy that anyone will succeed commercially with it unless they just set themselves up as the distributors of commodity open source hardware that does the job.

People do make shitloads of money selling commodities.


The network connection is an integral part of what makes our system work, and the ubiquity of smartphones is what makes it viable at scale. In terms of trusting a startup, we're working on exposing more of what we're doing to demonstrate its safety. The first part of that is a paper we're working on publishing this Spring at security conferences that details how Clef works using best practices and established security protocols to keep a user's information safe.


I'd like to say, big props for talking earnestly about your solutions to these problems -- that really does go a long way towards building trust. I've seen startups that basically take the "it's secret sauce, we can't tell you how it works!" approach, and that's more or less the kiss of death for anyone in security. :)


Thanks! We definitely want to be open about what we're doing to help demonstrate the safety we're offering. Making that dialog intelligible to users of different sophistications in terms of security knowledge is a major challenge for us.


Nice, but only two sites are using it so far, neither of which I've heard of, and one of which seems to be a hyper-local enterprise.


These types of integrations have a chicken-and-egg challenge (who would work with clef before they have a large user base ?)


I'm actually fine with it as an app developer. Easy Rails Integration, Django app, Wordpress plugins could be something they might want to look at.

To me, this looks like a free version of https://www.authy.com/


Authy is doing great stuff, but they're still relying on passwords, which we want to eliminate entirely. We're working on contributing to some Rails gems that would make it much easier to integrate, but the Django and Wordpress suggestions are also good ideas that we'll follow up on.


I just threw a proof-of-concept WordPress plugin together. I'll flesh it out a little tonight & send you a Github URL to check it out.


Thanks, that's awesome.


I'm not using this, for the same reason I'm not using FB to log in everwhere - I don't want anyone knowing every site I log into.

This is one of the big advantages of BrowserID/Persona, no individual site controls anything.


This is a fair point. We really want to be respecting users' privacy, which is one of the reasons we've focused on a business plan that doesn't count on selling that data about our users. We do think that a central identity is a better solution for many security reasons, but also for many privacy issues that stem from the security problems.


How can you prove that you aren't selling this information? It certainly would be the most profitable thing to do, so from the customer's perspective, you certainly have an incentive to betray my trust.


It's part of our terms of service now that we can't sell the information, I'm not sure what else we can do to prove that other than continue not doing it.


Just the other day a friend came up with seemingly the same idea. Since he was there he explained to me his design and I tore a huge hole in it. Then I explained to him that it was pure luck I could see the problem, a far more likely outcome is that the problem would be there but I won't see it.

Bottom line, I wouldn't touch it with a 10-foot pole until tptacek stakes his name on it.


This. The first thing I assume when I have a "good idea" related to security is that I'm missing something.

The alternative is assuming that I'm smarter or have more insight than everyone else who has thought about the same problem. And I know that's probably not true.


We have done a lot of security research and have written a paper which we will be submitting for publication in security conferences in the Spring. We are not smarter than everyone else, and are following the work of several people who are smarter than ourselves. Everything we are doing uses current standards and best-practices that were established by other experts.

What the security community hasn't done, though, is find a way to make all of those best-practices and security algorithms accessible and easy to use for a casual user. What Clef does is wrap up a lot of the security which we all know works for a consumer that doesn't have to understand it.


I wanted to let you know that I read this comment, but knew I needed something to say to justify adding one:

I would like to note for future reference, that my position here is not outright dismissal, but extreme skepticism.

PS. That this appears to be a centralized solution is a deal breaker for me, at least for important accounts.


Do you think there's any chance that security researchers have disregarded UX factors?


At the moment we're in the good situation of having good security that's hard to use, which is much better than easy to use but broken security.

UX stuff comes after the security stuff is sorted out. Having pretty but useless security is worse than no security. Unfortunately there is plenty of security stuff which looks nice but which is broken.

None of this is any kind of comment on OPs scheme! I'm gently worried about malicious people being able to shut down all my accounts remotely. And it's a bit disturbing that a lost phone means all my accounts are now compromised - but I guess that most people save passwords anyway.

I'd like to see other people prodding at this because passwords really do suck.


Many, sure. All, I am doubtful of. Social Engineering is one of the key methods of introducing security vulnerabilities into an otherwise secure system. A security researcher with this in mind would have to consider UX factors at least in the context of weather or not they could confuse the user into giving away vital data. (Example: People being unable to remember complex passwords and pasting them to their monitor with sticky notes.) So usability concerns are entirely in the realm of a security model.


So, we're degrading QR codes to make them friendlier now?

I feel like a service like this would have been better served if they had released with a major site as a partner. I get that there is a cart/horse aspect to new authentication methods, but a big cart would have helped this horse.


So, we're degrading QR codes to make them friendlier now?

Yup http://research.swtch.com/qart and https://news.ycombinator.com/item?id=3836935


I feel like there are holes in this but I am definitely delighted to see people experimenting in this space; I've been feeling like passwords need to die for a while now.

Q: How do you log onto a Clef-enabled site from your phone?


This is a feature which will be out with our next release. When we detect the visit from a smartphone, we change the QR to a button, and when it is pressed we redirect you through the app, where you verify your PIN, then redirect you back to your browser where you are logged in.


Unless I'm massively mistaken, this is basically just using Clef as a delegated authentication provider, except your phone performs automatic login to Clef a key that is not visible to you.

The big problems here are:

1) If Clef ever goes away, your entire userbase is locked out from their accounts.

2) If Clef is ever down, your entire userbase is locked out from their accounts.

3) The phone becomes a single point of security failure.

Passwords can obviously get better, and I think that using something like personal mobile devices to help fix the issue is a step in the right direction, but I'm not sure that this is the right solution.


1) If Clef ever goes away, you still own all of the data about your users, including their email, and you can easily send them a link to create a password for your site.

2) You are depending on our uptime, and of course this is a huge priority for us.

3) As we've said elsewhere, Clef is two-factor authentication and a lost phone is both protected and easy to deactivate.

Thanks for pointing out where we can be more clear in addressing these potential problems, but these security problems are things which we have considered and solved for.


Regarding the first point, that is true, assuming that the user used a real email and didn't typo it, still has access to that email account, etc. Delegated auth is wonderful, but hitching your auth wagon to a new company makes me nervous. That's not your fault, and it's not something I expect a solution for, because it's just the natural state of startup affairs. I do hope you guys get big enough that it's not a concern!

I retracted the 4th point, since it was a bit unclear, but my concern was that since you're almost always going to be sharing the same network with the mobile device and authenticating device, you can get both the data out from the phone and the data in from the Javascript; one of the marketing pieces is "log in once, you're logged in everywhere", which means that if I can steal whatever cookie gets set, I've got full access. This is a problem that the big delegated auth players (Google, Facebook) work very hard to solve by making sure that even a slight change in access patterns means session invalidation or a reauthentication challenge, because if you can steal a Facebook or Google session, the same concerns apply. Some kind of assurance that you all employ the same kinds of paranoid measures would be great.


That's a really good point about the cookie theft. We sign our cookies to make sure that they're inaccessible to others, but making sure they're non-transferrable/stealable is worth more consideration.


I think there's a big chicken-and-egg problem here since why would websites use it before there are users?

But it also seems like it would be too much of a hassle for users. If they let their browser or Lastpass save the passwords, they can log in automatically without multiple steps involving a phone. I mind having to take out my phone for regular 2-factor authentication but I normally only need to do that once for each device. I also find that I would rather type in a couple digits than wait for a camera and QR code recognition.


Clef offers every website drastically increased security for their logins from day one, and the site doesn't have to worry about re-implementing security best practices. Also, since Clef is a single-sign-on solution, only one QR code needs to be scanned per session.


I seem to remember Google offering something very similar to this that relied on scanning a QR-code on a known device? (I could be mixing stories though)


You're right. Google had an "Open Sesame" project a while ago that used a QR code on top of a password to make logging in more secure. Doing both was just an extra pain and users didn't enjoy it, so they gave up on it.


so based on that information, you're thinking the combination of the two was the major pain point ?


We've actually done a lot of consumer research and there are a few things that we think made the Open Sesame project uninteresting to consumers. The first is that it was too early and too few people had smartphones, the second is that it only increased complexity for security, and the third is that it was replaced by the SMS message as second-factor which was more broadly available and more easily understood.


What if you want to sign in to a website on your mobile?


This is a feature that is coming soon. Instead of scanning a QR code, you will be shown a button. Tapping it will route you through our app, where we will confirm your PIN, and then back to your browser where you will be logged in.


  Very cool - and I say this with spending a lot of time in the space.


OneID is a similar service. Unlike OneID, this service actually presents itself in an attractive way with a straightforward website which doesn't suck.


Thanks! Not sucking is a huge deal in this space!


looks interesting, they need to fix the mixed content warnings... hard to take'em serious when they don't have a secure website...


this actually seems to be something up with Vimeo--we'll look into what's causing that, but it doesn't affect security. unless you see something different?


The URL you're using for the iframe works under HTTPS.


How is it two factor if you don't also give a password? Is it not just a different one factor?


There is a PIN to open the app that serves as the knowledge-based factor.


Something similar http://launchkey.co/


We've been paying attention to launchkey, but it seems that they are using a hardware dongle to do the authentication, which we find pretty unappealing.


Oh interesting! Where did you find that out? I was right next to the team that started launchkey at startup weekend. There was no mention of a dongle in their demo.


I don't have a telephone. What are my options?


A telephone or a smartphone? We've actually architected a solution for non-smartphones, but it's not implemented yet.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: