-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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). |
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.
The text was updated successfully, but these errors were encountered: