Show HN: Solving a very old problem — passwords
clef.io
clef.io
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.
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.
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?
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...
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.
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.
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.
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.
[1] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al... [2] http://zetetic.net/software-onetime
Disclaimer: my employer makes OneTime.
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.
The video only shows one factor of authentication. There's no password involved (which is normally the first factor).
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.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.
"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)
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.
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.
To make it more secure it should be two factor. Users enters code, scan and then the phone gives him a unique to enter.
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.
Good luck though
Am I misunderstanding something?
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?
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.
To me, this looks like a free version of https://www.authy.com/
This is one of the big advantages of BrowserID/Persona, no individual site controls anything.
Bottom line, I wouldn't touch it with a 10-foot pole until tptacek stakes his name on it.
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.
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.
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 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.
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.
Yup http://research.swtch.com/qart and https://news.ycombinator.com/item?id=3836935
Q: How do you log onto a Clef-enabled site from your phone?
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.
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.
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.
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.
Very cool - and I say this with spending a lot of time in the space.