Why we need real cryptography instead of passwords | Hacker News Reader

Why we need real cryptography instead of passwords

blog.getclef.com

19 pointsaruss17 comments

Looks interesting. I'm disappointed that I have to give you an email address in order to read about the security & threat model.

Why not make it public?

Right now, we're working to create an easy to digest summary of our security architecture, so this is just a temporary measure.

I just shot you an email and will follow up with a more in depth summary.

Out of curiosity, could a crypto-oriented person suggest the effective difference between a public/private key system, and a password system where the password is as long as a public key would be?

Given that most of the password-cracking articles focus on length of password being important regarding cracking time, it seems to this crypto-naif that a public-key-length password would do 99% of the job of moving to a public/private key system. I understand that you may as well use keys as a password of that length isn't human-memorable, but I'm curious as to what the effective difference would be.

A public key system allows you to prove that you know a secret (the private key) without revealing the secret. To authenticate with a private key system you have to share the secret with the entity you're authenticating to, so you have to trust that entity to keep the secret. The fundamental problem with passwords is not that they're easy to guess, it's that using a password necessarily entails revealing the password.

> using a password necessarily entails revealing the password

Not always - the Secure Remote Password protocol doesn’t reveal the password to the server: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Yeah, but no browsers implement SRP (AFAICT) so this is a moot point. In today's world, using a password on the web means typing that password into a web form, at which point all bets are off: you have no control, or even knowledge, of how that password is processed from that point on. The only thing you can be even slightly confident of is that if you're typing the password into an HTTPS page then you're somewhat safe against MITM attacks. But there's no way to protect yourself against the incompetence (or maliciousness) of whoever you're doing business with.

Thanks, that makes more sense. I was expecting a more mathematical than philosophical answer, but in hindsight, I was wrong to do so.

That's actually a really good question that this post wasn't focused on. What's cool about the key pair is that the only information that is passed around is the signature, which is only valuable for a few seconds. The key itself is never transmitted and so it can never be intercepted.

That's a separate problem from the length of cracking, but an equally important one with regards to security.

Also, it would be pretty hard to remember even a single password that long...

We do have SSL certificates you're advocating for. I have two installed in my browser right now. No one but their issuers lets me log in using those.

I get the push for Cleft but fussing around to find my phone which is no more, and probably less, secure than my laptop is not really a win. It may be nice for shared workstations but those are largely on their way out. Nowadays, we have more computers around than people to use them.

This really is a big option...but I can't see this taking off either. Secure Email Digital IDs have been out for forever and very few people use it...even fewer webmail clients use it. What seems to be obvious, doesn't appear to be catching on at all.

I can't imagine users being satisfied with a solution that requires them to either use a specific machine or have a physical artifact with them to login. It just feels too much like a step backwards when everything else is moving toward living on the cloud. Clef looks interesting, but what's the user story when someone's phone dies?

Every security article I see either tries to drastically expand the entropy of the user's key (password or otherwise) or expand to some sort of two-factor authentication. Obviously that's better, long term, but I get the feeling passwords are here to stay for the foreseeable future. I'd love to see an actually secure authentication solution that can be used by someone with nothing other than their memory. Is anyone doing any work on ways to make authentication more secure with a low key entropy?

For Facebook or Hacker News: Yes, most users want to avoid the need for a physical artefact to log in.

For a bank website: No, most users are happy to require a physical artefact because they recognise that it helps protect their money. If your phone dies then you are simply be unable to access your bank account until you recharge it.

Exactly. Good two-factor authentication is not hard. World of Warcraft, for example, has had an excellent real-world implementation for years now. It's actually sufficiently not hard that I'm not sure there's really room for much innovation in that space (unless you count banks actually using it to be innovation).

What I'm saying is we need a better solution for Facebook and HN. There's some large subset of sites for which users will not tolerate a physical artifact or convoluted multi-step process. Within those constraints, and with the understanding that we'll never be able to do as well as 256-bit private keys or two-factor, I'm wondering if we can't still do significantly better than alphanumeric passwords.

Nice! A year ago I made a demo website that works pretty much the same way: http://sandbox.self.li/qr-login/

Same idea but running in your browser:

http://dswi.net/

Your 'Clef' URL at the end is broken. Toss an https:// on the front.

woops! good catch.

Reply on news.ycombinator.com