Improving password-based authentication

Improving password-based authentication
Improving

password-based
authentication
Frank Denis @jedisct1

What’s wrong with
passwords?

Passwords are reused: find one, pwn many.
Companies don’t always communicate
about a breach until they are forced to.
Which can have side effects if discovered
when you are negotiating an acquisition
by Verizon.
Breaches happen all the time, even big
corporations and banks cannot be trusted.

API keys are passwords, too.
Committed to public repositories.
Present on present and past employees
laptops.
Long-term, shared secrets.
Intentionally leaked by customers because
you asked them to!

OpenDNS 
support 
forum

Password!
https://support.opendns.com/hc/en-us/community/posts/220033527-OpenDNS-Blocking-never-set-it-up
Many more leaks happen due to bad design. 
Ex: HTTP_REFERER

Face it: passwords are here to stay
Convenient, universal way to log in from
anywhere, on any device.
Today’s passwords might be less terrible

than 10 years ago.
This is something you know, not something

that you have. Stealing them requires a $5

wrench.

How to survive a
password breach

Database encryption
Useless against other threats we are going

to talk about soon.
Useless if the key is leaked.
Useless if passwords are leaked using a

post-decryption vulnerability.

Hashing
Gives a false sense of security
Deterministic

Can be broken by using Google.

Hashing with a salt
Defeats rainbow tables.
This is not enough.

Hashing with a salt
Every time a new breach is announced,
about 70% of the passwords were already
present in previous lists.
Lists of > 500 million passwords from
previous breaches can be freely
downloaded.
What about the remaining 30%?

Hashing with a salt
A personal cracking rig can run 100 billion
guesses per second.
An exhaustive search of all the possible 8
characters passwords can be performed by
a single rig in less than a day.
But wait… it gets worse…

Hashing with a salt
Password entropy is almost always
overestimated.

Hashing with a salt
Humans are bad at generating randomness.

Hashing with a salt
Modern password crackers use
permutations, substitutions, Markov chains,
and neural networks in order to efficiently
probe the key space.
Smart contracts can reward people for
cracking passwords.

CPU-hard hash functions
PBKDF2, bcrypt
Can be massively parallelized
A perfect fit for GPUs and ASICs
We’d like to minimize the advantage
attackers have over defenders.

Memory-hard hash functions
scrypt
Require a lot of memory: each iteration
requires data from previous iterations.
TMTO attacks.

2013-2015: password hashing competition
Winner: Argon2
For a given set of parameters, computing a
hash requires a fixed amount of silicon
(transistors, capacitors, routing).

2015-2019: Argon2 adoption
libsodium, libargon2
Now available for all programming
languages.
Quickly adopted by cryptocurrencies and

applications.
Not a good fit for JavaScript, though.

2019
We realized that some practical
requirements had been overlooked.
What we may need is cache-hard functions
instead of memory-hard functions.
Due to CPU caches, Argon2 is actually
worse than bcrypt for some parameters.

2019
Still, if you use any of the functions from the
previous slides, you’ll be in a far better
position than virtually everyone else in the
industry.
Yes, even with random parameters.

It could have been the
last slide, but…

Password hashing is an expensive
operation, done server-side.
Introduces a DoS vector.
Choosing optimal parameters is hard.

Client Server
password over TLS

Client Server
password over TLS
TLS termination

Client ServerEnterprise security gateway
SSL added and removed here!

Client ServerISP

Passwords can be found in application
logs, displayed on error pages.
Sent to 3rd party services (New Relic,
Datadog…)
Affected Facebook and Twitter.
Password hashing doesn’t do anything.

Insider threats. Cloud providers.
This is a stealth, passive attack.
Password hashing doesn’t do anything.
Running tcpdump on a production server
can be all it takes.

Passwords should not
be sent over a network
any more.

Public-key cryptography to the rescue
Passwordless SSH
Client certificates are widely supported by
web servers and browsers, but they’re
barely usable.
Private keys stay on the clients. Their public
counterparts being leaked is no big deal.

Deterministic keys from passwords
Derive keys from passwords; servers can
then use public keys for authentication.
h ← H(pwd)
(pk, sk) ← H2KP(h)
The client does the hard work (or a part of
it): no more DoS vector!
But this is deterministic; public keys can be
precomputed from password dictionaries.

h ← H(s, pwd)
But how does the client get the salt?
Deterministic keys from passwords
Client ServerS(sk, n)
Client ServerV(pk, S(sk, n))
Client Servern

h ← H(s, pwd)
Client Servern, s
Client Servername
But wait…

Now, the salt is public
Not secure against targeted
precomputation

A B?
A B?
x
?f(x)
Oblivious transfer

A Bg(xr
)
A Bxr
(mod p)
x, r g
f(x) = g(xr
)1/r
(mod p)
(V)OPRFs
blind(x)

A Bg(xr
)
A Bxr
x, r k
f(x) = g(xr
)1/r
(V)OPRFs
g(x) = xk
blind(x)
random oracle for A

Client Serverg ∘ blind(s)
Client Serverblind(s)
OPAQUE blind salts
h′ ← H′(pwd)
s ← H2S(h′)
s′ ← g(s)

Client Serverg ∘ blind(s)
Client Serverblind(s)
OPAQUE blind salts
s′ ← g(s)
h ← H(s, pwd)
h′ ← H′(pwd)
s ← H2S(h′)

Client Serverg ∘ blind(s), n
Client Servername, blind(s)
A shared session key can also be
computed.
User enumeration can be prevented.

The server doesn’t know the salt.
Defeats precomputation.
Every attempt requires an interaction with
the server.
Knowing the salt requires knowing the
password.
Proof of concept implemented for
Terrarium.

PAKEs

PAKEs
Password-based authentication.
Use cases:
More generally: secure key exchange from

low-entropy secrets. Ex: Magic Wormhole,

biometric authentication, pairing IoT devices,

QRCode-based pairing…
Bootstraping a PKI

The PAKE selection process
SRP and SCRAM can be improved.

Deployment
Requires tight coupling with operating

systems and web browsers.
Integration into TLS 1.3 is being considered.
May be a solid defense against phishing.
Browser vendors haven’t been involved yet.

Dependencies

Terrarium demo - Shows that PAKEs need

shared code between clients and servers, and
that WebAssembly can help with that.
SPAKE2+EE implementation for libsodium.
Now in libsodium 1.0.18 and wasm-crypto:

- hash-to-curve

- ristretto

- arithmetic to implement (V)OPRFs.
https://github.com/jedisct1/wasm-crypto https://sk.tl/66AuXfXS

Thanks!

Improving password-based authentication

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (13)

Semelhante a Improving password-based authentication

Semelhante a Improving password-based authentication (20)

Mais de Frank Denis

Mais de Frank Denis (7)

Último

Último (20)

Improving password-based authentication