Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support scrypt into SRP6a in order to avoid weak password storage #1

Open
fpietrosanti opened this issue Mar 14, 2015 · 1 comment
Open

Comments

@fpietrosanti
Copy link

The default key material storage of SRP is considered to be weak (see Solar Designer here http://lists.randombit.net/pipermail/cryptography/2015-March/007121.html) .

For this reason we suggest, following discussion on randombit cryptography mailing list, to integrate scrypt as an additional custom hashing method to SRP as described by Alfonso De Gregorio (see http://lists.randombit.net/pipermail/cryptography/2015-March/007123.html) .

It's suggest to use the the following scrypt library This ticket ishttps://github.com/dchest/scrypt-async-js (by Solar designer, see http://lists.randombit.net/pipermail/cryptography/2015-March/007117.html).

By improving SRP authentication, bundling it with scrypt KDF, the authentication protocol would also feature strong password storage server side.

@Tarang
Copy link
Member

Tarang commented Mar 14, 2015

It might be worth mentioning that SRP has been deprecated in meteor in favour of bcrypt. The package helped authenticate using node-ddp to the meteor server.

While the SRP mechanism still works for backward compatibility the new accounts system uses sha256 hashed passwords with bcrypt (10 rounds) ontop which should correct the material storage issue.

In changing the legacy SRP authentication this library matches the meteor one. It may be worth mentioning it on the meteor project (github.com/meteor/meteor).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants