overview and evolution of password-based authentication schemes

Overview and evolution of password-based authentication schemes

Ignat Korchagin

Passwords in Roman Empire

Ave, Caesar!

http://ancienthistory.about.com/library/bl/bl_text_polybius6.htm

• every night the watchword was changed

• used a “roundtrip” delivery mechanism with confirmation to distribute the password

http://ancienthistory.about.com/library/bl/bl_text_polybius6.htm

Passwords in modern world

createpassword?

“hunter2”hehe, no one

will ever guess

HTTP basic authentication

alice:example.com:hunter2

HTTP basic authentication

alice:example.com:hunter2

• simple

• password is sent in clear text

• HTTPS is needed to protect from eavesdroppers

• server DB leak compromises all the passwords

HTTP digest authentication• server stores Hash(alice:example.com:hunter2)


GET secret info


GET secret info

nonce


GET secret info

nonce

cnonce, Hash(Hash(alice:example.com:hunter2),nonce,cnonce)

HTTP digest authentication• passwords are not sent in clear text

• protected from replay attacks

• servers may store hashes of passwords instead of passwords themselves

• server DB leak compromises passwords for specific realm only

HTTP digest authentication• passwords are not sent in clear text

• protected from replay attacks

• servers may store hashes of passwords instead of passwords themselves

• server DB leak compromises passwords for specific realm only

BUT…

HTTP digest authentication• still vulnerable to MiTM

• still vulnerable to spoofed websites

• requires HTTPS

• vulnerable to dictionary attacks

HTTP digest authentication• still vulnerable to MiTM

• still vulnerable to spoofed websites

• requires HTTPS

• vulnerable to dictionary attacksFrom RFC 7616:

HTTP Digest Authentication, when used with human-memorable passwords, is vulnerable to dictionary attacks. Such attacks are much easier than cryptographic attacks on any widely used algorithm, including those that are no longer considered secure. In other words, algorithm agility does not make this usage any more secure.

As a result, Digest Authentication SHOULD be used only with passwords that have a reasonable amount of entropy, e.g., 128-bit or more. Such passwords typically cannot be memorized by humans but can be used for automated web services.

If Digest Authentication is being used, it SHOULD be over a secure channel like HTTPS.

HTTP OAuth

auth tokenGET

auth

token

HTTP OAuth

auth tokenGET

auth

token

• allows delegations

• does not need to use real credentials

• needs other methods to authenticate on authorization server

• HTTPS is needed to protect from eavesdroppers

HTTPS is hard

HTTPS is hard• problems with mixed content

• maybe fixed with implementing proper content security policy



• spoofed websites• similar domain names, same look and feel




• spoofed certificates• https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-

certificates-from-comodo-via-dangling-markup-injection/index.html

https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html




• spoofed certificates• https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-

certificates-from-comodo-via-dangling-markup-injection/index.html

• compromised keys and certificates• certificate revocation is hard

https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html

Can we do better?

Socialist millionaires• Socialist millionaire problem is a way for two

millionaires to check whether their wealth is equal

Socialist millionaires• EC curve: G - base point, n - order of G

• Alice and Bob have x and y respectively. Both want to know whether x==y.



Generate a2, a3, sG2a = a2*GG3a = a3*G

Generate b2, b3, rG2b = b2*GG3b = b3*G

G2a, G3a, G2b, G3b





G2 = a2*G2bG3 = a3*G3b

Pa = s*G3Qa = s*G + x*G2

G2 = b2*G2aG3 = b3*G3a

Pb = r*G3Qb = r*G + y*G2

G2a, G3a, G2b, G3b

Pa, Qa, Pb, Qb





G2 = a2*G2bG3 = a3*G3b


G2 = b2*G2aG3 = b3*G3a


Ra = a3*(Qa-Qb) Rb = b3*(Qa-Qb)

G2a, G3a, G2b, G3b

Pa, Qa, Pb, Qb

Ra, Rb





G2 = a2*G2bG3 = a3*G3b


G2 = b2*G2aG3 = b3*G3a



a3*Rb == Pa-Pb b3*Ra == Pa-Pb

G2a, G3a, G2b, G3b

Pa, Qa, Pb, Qb

Ra, Rb





G2 = a2*G2bG3 = a3*G3b


G2 = b2*G2aG3 = b3*G3a




G2a, G3a, G2b, G3b

Pa, Qa, Pb, Qb

Ra, Rb

a3 * Rb = b3 * Ra = (Pa - Pb) + (a3 * b3 * (x - y)) * G2

Socialist millionaires• Socialist millionaire problem is a way for two

millionaires to check whether their wealth is equal• can be used to verify whether two parties posses the same secret

• a passive attacker learns nothing about the protocol and its outcome

• MiTM can do no better than passive attacker except disrupting the communication channel

• even if one of the parties is dishonest, he learns nothing more that the protocol outcome

• unlike most other zero-knowledge proofs requires O(1) protocol iterations

• is adopted and has good history

OTR SMP• Uses 1536-bit group calculations


• BUT: LogJam!


• BUT: LogJam!• 512-bit broken

• 1024-bit probably

• 1536-bit is very close!

Themis SMP vs OTR SMP• Improving SMP

• moved all cryptographic operations in ECC domain

• modern (boring) cryptography (ed25519)

• timing attacks protection

• fast and performant

• reduced memory footprint

• support for many high-level languages

• simple API

• GitHub: https://github.com/cossacklabs/themis

https://github.com/cossacklabs/themis

SPAKE2• EC curve: G - base point, n - order of G, M,N - known fixed points on the curve

• Alice and Bob know w.



Generate xX = x*G

T = w*M + X

Generate yY = y*G

S = w*N + Y



Generate xX = x*G

T = w*M + X

Generate yY = y*G

S = w*N + YT, S



Generate xX = x*G

T = w*M + X

Generate yY = y*G

S = w*N + Y

K = x*(S - w*N) K = y*(T - w*M)

T, S

SPAKE2• PAKE - password-authenticated key agreement

• basic SPAKE2 requires only 1 roundtrip

• simple, requires small number of asymmetric cryptographic operations

• easy to implement

• provides a negotiated secret key as a protocol outcome

SPAKE2• PAKE - password-authenticated key agreement

• basic SPAKE2 requires only 1 roundtrip

• simple, requires small number of asymmetric cryptographic operations

• easy to implement

• provides a negotiated secret key as a protocol outcome

• Example: SPAKE2 (https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03)

https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03

SMP vs SPAKE2SMP SPAKE2

• provides mutual authentication • provides mutual authentication


• provides mutual authentication • protected from MiTM

• provides mutual authentication • protected from MiTM


• provides mutual authentication • protected from MiTM • requires 3 roundtrips

• provides mutual authentication • protected from MiTM • requires 2 roundtrips





G2 = a2*G2bG3 = a3*G3b


G2 = b2*G2aG3 = b3*G3a




G2a, G3a, G2b, G3b

Pa, Qa, Pb, Qb

Ra, Rb



Generate xX = x*G

T = w*M + X

Generate yY = y*G

S = w*N + Y

K = x*(S - w*N) K = y*(T - w*M)

T, S



Generate xX = x*G

T = w*M + X

Generate yY = y*G

S = w*N + Y

K = x*(S - w*N) K = y*(T - w*M)

T, S

Key confirmation?


• provides mutual authentication • protected from MiTM • requires 3 roundtrips • slower

• provides mutual authentication • protected from MiTM • requires 2 roundtrips • faster



• ~30 times slower in pure C


• ~30 times faster in pure C



• ~30 times slower in pure C • ~3 times slower in Python


• ~30 times faster in pure C • ~3 times faster in Python




• negotiates 2 shared secrets



• negotiates 1 shared secret





G2 = a2*G2bG3 = a3*G3b


G2 = b2*G2aG3 = b3*G3a




G2a, G3a, G2b, G3b

Pa, Qa, Pb, Qb

Ra, Rb




• negotiates 2 shared secrets • provides zero-knowledge

guarantee



• negotiates 1 shared secret • has some implementation caveats



Generate xX = x*G

T = w*M + X

Generate yY = y*G

S = w*N + Y

K = x*(S - w*N) K = y*(T - w*M)

T, S



Generate xX = x*G

T = w*M + X

Generate yY = y*G

S = w*N + Y

K = x*(S - w*N) K = y*(T - w*M)

T, S

To successfully complete the protocol:• the peer may not even know w (the real secret

information)• but only w*M and w*N (its public derivatives)

Possible use-cases

Possible use-cases

Encrypted communication (K1)

• Automatic key rotation for long-lived encrypted connections

Possible use-cases

SMP (or SPAKE2 with confirm)



Possible use-cases




save negotiated key

Possible use-cases





save negotiated key

Conclusions• Zero-knowledge protocols are useful building blocks for

enhanced security and privacy preserving protocols• They can be useful in a scenario where one of the protocol participants may

be malicious

• You may use SPAKE2 for many real world tasks, but you have to be aware of the caveats

• Socialist millionaire protocol provides more security guarantees, although with some performance penalty

Links• Paper: https://www.cossacklabs.com/files/secure-

comparator-paper-rev12.pdf

• SMP code: https://github.com/cossacklabs/themis

• SPAKE2 code: https://boringssl.googlesource.com/boringssl/+/master/crypto/curve25519/spake25519.c

• sctest.c: https://gist.github.com/secumod/d3a064ee93e3eda74aebd379e60ede66

• spake2test.c: https://gist.github.com/secumod/5c35c067a4e25fbe038f09a2706b236b

https://www.cossacklabs.com/files/secure-comparator-paper-rev12.pdf

https://github.com/cossacklabs/themis

https://boringssl.googlesource.com/boringssl/+/master/crypto/curve25519/spake25519.c

https://gist.github.com/secumod/d3a064ee93e3eda74aebd379e60ede66

https://gist.github.com/secumod/5c35c067a4e25fbe038f09a2706b236b

Thank you!

Questions?

overview and evolution of password-based authentication schemes

Internet