
Show HN: Solving a very old problem — passwords - brennenHN
https://clef.io/
======
jetti
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.

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

~~~
cheald
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...](http://www.zdnet.com/blog/igeneration/googles-qr-code-log-in-
experiment-concluded/14679)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------
pavel_lishin
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
These types of integrations have a chicken-and-egg challenge (who would work
with clef before they have a large user base ?)

~~~
suhastech
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/>

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

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

~~~
brennenHN
Thanks, that's awesome.

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

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

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

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

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

~~~
unimpressive
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
Do you think there's any chance that security researchers have disregarded UX
factors?

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

------
eddieroger
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
_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>

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

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

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

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

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

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

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

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

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

~~~
brennenHN
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
so based on that information, you're thinking the combination of the two was
the major pain point ?

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

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

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

------
czbond

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

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

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

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

~~~
jessepollak
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
The URL you're using for the iframe works under HTTPS.

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

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

------
amccloud
Something similar <http://launchkey.co/>

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

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

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

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

