Show HN: Solving a very old problem — passwords

by brennenHN • 14 years ago

45 82 14 years ago

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.

niggler• 14 years ago

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

suhastech• 14 years ago

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/

czbond2• 14 years ago

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

flyinglizard• 14 years ago

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

brennenHN29• 14 years ago

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

Navarr2• 14 years ago

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

brennenHN29• 14 years ago

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.

czbond2• 14 years ago

  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.

Navarr2• 14 years ago

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.

jetti5• 14 years ago

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)

a3_nm• 14 years ago

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?

eddieroger• 14 years ago

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.

sp332• 14 years ago

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

DenisM• 14 years ago

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.

unimpressive3• 14 years ago

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.

woah• 14 years ago

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

brennenHN29• 14 years ago

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.

taf2• 14 years ago

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

jessepollak• 14 years ago

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?

simonbrown• 14 years ago

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

amccloud2• 14 years ago

Something similar http://launchkey.co/

brennenHN29• 14 years ago

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.

amccloud2• 14 years ago

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.

venomsnake• 14 years ago

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?

brennenHN29• 14 years ago

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.

jetti5• 14 years ago

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.

brennenHN29• 14 years ago

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.

jetti5• 14 years ago

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

cheald5• 14 years ago

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

uvdiv2• 14 years ago

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.

jetti5• 14 years ago

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.

yuliyp• 14 years ago

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

brennenHN29• 14 years ago

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.

patrickod• 14 years ago

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)

brennenHN29• 14 years ago

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.

angryasian• 14 years ago

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

bobcattr2• 14 years ago

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.

brennenHN29• 14 years ago

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.

bobcattr2• 14 years ago

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

gcr5• 14 years ago

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?

kaolinite• 14 years ago

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

brennenHN29• 14 years ago

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.

egypturnash• 14 years ago

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?

brennenHN29• 14 years ago

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.

AndrewDucker• 14 years ago

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.

brennenHN29• 14 years ago

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.

gcr5• 14 years ago

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.

arikrak• 14 years ago

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.

brennenHN29• 14 years ago

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.

vegas• 14 years ago

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.

brennenHN29• 14 years ago

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.

cheald5• 14 years ago

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. :)

gcr5• 14 years ago

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

brennenHN29• 14 years ago

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

cheald5• 14 years ago

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.

brennenHN29• 14 years ago

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.

cheald5• 14 years ago

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.

glomph• 14 years ago

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

brennenHN29• 14 years ago

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

Show HN: Solving a very old problem — passwords

Related Stories