
Why we need real cryptography instead of passwords - aruss
http://blog.getclef.com/?p=54
======
zackelan
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?

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

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

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

~~~
MarkMc
> 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>

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

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

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

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

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

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

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

------
lisper
Same idea but running in your browser:

<http://dswi.net/>

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

~~~
brennenHN
woops! good catch.

