On Fri, Mar 13, 2015 at 9:25 AM, Fabio Pietrosanti (naif) - lists
<li...@infosecurity.ch> wrote:
> Hi all,
>
> SRP is a very cool authentication protocol, not yet widely deployed, but
> with very interesting properties.
>
> I'm wondering how strong is considered the storage of the password's
> related material strength?
>
> I mean, from a passive/offline brute forcing perspective, how can be
> compared scrypt vs. SRP's server-side storage of passwords?
>
> Does anyone ever considered that kind of problem?
>
> Because SRP protocol is cool, but i'm really wondering if the default
> methods are "strong enough" against bruteforcing.
scrypt Vs. SRP? There is no such dilemma, as they serve different
purposes. The reality is that you should use your password hashing
scheme of choice --- say scrypt --- *and*, if you want to get rid of
the X.509 PKI business, your PAKE protocol of choice --- say SRP 6a
--- to provide mutual authentication.
Yet, you need to be very careful if you adopt SRP:
If an attacker learns a user's SRP verifier (e.g., by gaining access
to a server's password file), the attacker can masquerade as the real
server to that user, and can also attempt a dictionary attack to
recover that user's password. [RFC5054]
The cost of a password recovery attack against the SRP password
verifier (i.e., preimage security) will dependent on the known attacks
to the hashing scheme used to instantiate the SRP protocol. More
specifically, if the hashing scheme is a simple hash function, offline
dictionary attacks will be easy to mount and you will get no security
whatsoever. Still, if the (password) hashing scheme provides better
security guarantees (e.g., scrypt) the final construction will benefit
from its adoption.
In fact: as long as the password verifier remains opaque to the
server, it is possible to retain some freedom of choice for the
hashing scheme used client-slide (i.e., the client computes x =
scrypt(passphrase,salt,C,password,dkLen) and v = g^x mod N and the
server stores {I,salt,v}, where I the user identity, salt is the
user's salt, and v the password verifier).
At the same time, replacing a cryptographic hash function with a
password-based KDF makes the overall password-management harder and
impacts the UX...
Take care.
[RFC5054] http://www.ietf.org/rfc/rfc5054.txt
-- Alfonso
tweets @secYOUre
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
