
Why We Might Be Stuck With Passwords for a While - zdw
http://time.com/3088934/password-alternatives-biometric-federated-two-step-sign-in/
======
drdaeman
Where is PKI-based sign-in? Why the heck every-fucking-one is so obsessed to
move your identity to third parties (email, domain or webpage providers) and
disregards one of the most sane, obvious, flexible and secure (if implemented
properly) concept out there?

Added: My points are:

\- (Security) They are immune to attacks on websites. All attackers would
extract is a public key.

\- (Flexibility) They are social, yet privacy-respecting. When you want to
keep your identity across multiple services — you use the same key. When you
don't want so — you just generate a new one — it's free. Some variants (like
OpenPGP) have web-of-trust out of the box.

\- (Flexibility) They are supported on almost every modern system out there —
if we're considering X.509 client certificates (probably not the best option,
but). Just polish the damn UI for those already, please.

\- (Sanity) They are something user actually possesses, not temporarily leases
like a Facebook account, email address or domain name.

\- (Flexibility/security) They could be stored as securely as one wishes. Keep
those in a file (your OS or browser's keystore, actually) if you don't care,
and HSMs are already here for those who want them.

\- (Flexibility/security) They could be easily synced across the devices. Just
escrow the key material with other key — derived from a password, if you wish.

\- (Security) They could be mass-revoked. Not easy and not flawless, but
there's OCSP. There're CRLs, too (although those suck). Certainly better than
running across multiple sites if one had used the same (compromised) password
with them.

~~~
skywhopper
I'm pretty sure that's what was being referred to when the author mentioned
corporate drones carrying around fobs. Generally those fobs contain the keys
for PKI auth in secure-hardware form.

However, having had to deal with using these myself, I'm not sure I would
agree that PKI auth is "sane", "obvious", or "flexible".

As for your other points, without a hardware-secure token, I don't think PKI
is secure in the least. You're one zero-day browser crack away from revealing
your private key. The solution to that of course is to require a passphrase,
and oops, we're back to the original problem.

~~~
hamburglar
> You're one zero-day browser crack away from revealing your private key.

You're still better off than any password scheme, which is often attacked from
the server side. And the lovely thing about the PKI method is that you can
invest as much or as little as you want into protecting the private key and
have the server not care even a little. On the weak end is the unprotected
private key file on your hard drive, followed by a private key that's
passphrase-protected (and even with this, there's a spectrum of configurable
behavior governing how long it stays decrypted), followed by private keys on a
physical device, followed by a physical device that requires two-factor
access.

------
cypherpunks01
Some of this seems fairly uninformed, which is surprising because of the
author's background.

"First, it’s easy for programmers to deploy a standard username/password
setup. They more or less just push a button in their app-building toolkit."

"Two-factor sign-in: ... The problem, and it’s a big one, is that you can’t
really carry a different doohickey around for each of your passwords."

~~~
DaCapoo
I agree.

"Another good practice is just to ask for passwords less often. If you’re
signing in every day from the same computer in your basement, you’ll notice
that Google hardly ever asks you to prove who you are."

I'm not sure if he's referring to Google asking for a second form of
authentication when you log in from an unknown location (such as sending you a
text message with a random number in it, which is unrelated to entering your
actual account password) or if he doesn't understand state management with
cookies. You obviously won't be asked to reenter your password if the session
cookie has been set in your browser and you have a valid session on the
server.

------
tubbs
> Yes, passwords are awful and don’t work.

Passwords are awesome. A bigger, better solution is immanent, but a password
does the job just fine for most uses. Passwords get a lot of flack for a
problem that isn't the concept of a password's fault, but the fault of those
who use poor passwords or reuse them across dozens of applications.

Either way, I'm excited to see what comes next.

~~~
dllthomas
"The concept of a password" has two big problems:

1) They're symmetric. I need to protect the thing I need to provide. If we can
contrive to make sure that the thing I need to provide it to can be safely
trusted, then this problem only manifests itself in the face of password
reuse, but assumptions break sometimes.

2) Enough entropy to be uncrackable is starting to be enough entropy to be
difficult to remember.

Password safes and similar address both of these - at the expense of increased
exposure to slightly different threats but for a net win. They're a slight
departure from "the concept of a password", though, I'd say.

------
yock
The article reads like a straw man argument in favor of begrudgingly accepting
password auth for the time being. It's disappointing that he has omitted
mention of things like Persona, browser certificates, or even the Google
Authenticator app (which completely solves his problem with 2FA).

~~~
freehunter
I actually have a problem with things like Google Authenticator. I use it to
secure the login for my Digital Ocean account. Worked great, until my phone
broke. When I signed into Digital Ocean with a new phone... well, of course
Google Authenticator doesn't know how to generate a new compatible code. That
part is controlled by a QR code when you enable 2FA, and you can't get back to
it without logging in. Same thing with securing the admin login to a site I
run. When I switched phones, I lost my login.

Sure, there's a way around it. Digital Ocean lets you disable 2FA with an SMS
code. Then I can just log in, set up 2FA again, and have it working on my new
phone. But then I fixed my old phone and switched back. So I had to do it all
over again.

Clef worked great, until someone with a Windows Phone joined the team and
needed to log into the site. Suddenly our authentication method of choice, one
we were really happy with, wasn't an option because Clef doesn't make a
Windows Phone app.

These are the problems the author seems to try to point out. Passwords at
least work every time you type them in, from any platform. Passwords aren't
tied to Google or Apple, passwords don't shun Microsoft platforms simply
because there aren't enough users. If your users have to buy an iPhone just to
be able to log in, or if they lose the ability to log in because they replaced
their phone (something that happens _all the time_ ), it isn't a solution at
all. They're going to end up going back to passwords (like we did) because
nothing else works as well as passwords.

And that's not a high bar to get over!

~~~
bad_user
Any method of authentication that's more secure that simple passwords is going
to be more inconvenient. 2FA is no exception.

~~~
freehunter
It doesn't have to be though. Clef is 100x easier than using a password, and
dead simple to implement. Nothing to remember but your phone, and nothing to
change at regular intervals. Google Authenticator is a little more
inconvenient, but not by much.

Of course, as my first comment pointed out, both of those became _very_
inconvenient for me. But they don't have to be. What if Clef, instead of being
proprietary, was a public property? Anyone can write a Google Authenticator
application, which is why one exists on Windows Phone. Google has written zero
software for Windows Phone, yet Authenticator works.

2FA doesn't have to be more inconvenient. In fact, it should be more
convenient than passwords, because passwords need to be remembered and
changed. There's no excuse.

~~~
dragonwriter
> 2FA doesn't have to be more inconvenient. In fact, it should be more
> convenient than passwords, because passwords need to be remembered and
> changed.

The second factor (the "thing you have") in 2FA doesn't need to be remembered
or changed. The first factor (the "thing you know"), which usually _is_ a
password, has to be remembered. (It may be somewhat less important to change
it than in a single-factor password-only scheme.)

~~~
freehunter
With a good 2FA system, you can use a junk password because the chances of
someone having both factors is next to zero. Using hunter2 as a password
instead of gEtRAn8s_dr6Spepe doesn't matter because guessing the password is
impossible unless they have your other factor, and even then it's going to
slow them down quite a bit. Especially if your other factor is stored on your
phone, which itself requires a password or fingerprint or both to get into.

~~~
dragonwriter
> With a good 2FA system, you can use a junk password because the chances of
> someone having both factors is next to zero.

If you use a junk password, then the chance of them being able to secure both
factors is essentially equal to the chance of them being able to secure the
other factor. Whether slowing them down matters really depends on context --
for most applications that may be an acceptable risk (if either the value of
the access goes down with a delay or you will be able to report the loss in a
way which prevents a slowed attacker from gaining access -- and its unlikely
that an attacker will be motivated enough to prevent you from doing so -- this
makes sense. This is not always the case.)

~~~
freehunter
You make good points. What I'm really trying to say is, someone sitting in
Russia can't really take my phone while I'm here in the US. That's not the
case with passwords. And it's not plausible to think there's someone who can
both steal my phone _and_ has access to my password for a given account,
unless that person knows me. The only hope they have is using a rainbow table
or dictionary attack. With most sites these days rate-limiting the login
process, that's hardly plausible either.

What I'm saying is, even basic 2FA makes it almost impossible for someone to
steal your credentials in the fashion that we are used to. It doesn't just put
us on par with the criminals like most security does, it puts us one step
ahead for the first time in over a decade. And it can be easy and convenient,
because you don't need billion-character passwords since the attacker needs to
be physically near you to steal your second factor. There are easy ways to
make it better, just no one has done it yet (because there's no money in it).

------
trickyager
The shallow writing of this article aside, I think it overlooks a rather
promising authentication scheme by Steve Gibson.
[https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

------
bigtech
Another important point is that users already consider passwords to be a
hassle and have little patience for anything that makes it harder to access
resources online.

