Need Password Security expert endorsement

[ericelliott]

I want to make sure that the Node / io.js community has a password security library they can trust. In 2013, I researched all of the libs I could find and found serious security flaws in all of them. I know it's impossible to make it perfect, but we need to ensure that there is something that at least raises the bar enough that a random script kiddie can't cause multi-million dollar disaster, PR nightmares, and personal loss to users.

I'm not a password security expert. I'm asking for your help. This has already been reviewed by many security experts, but I know there is room for improvement, and I want to make sure that users have a clear indication about which library they can count on to really work to make their users more secure. Please review this code carefully. Attack it with everything you've got, and then file issues here. I'll give you public credit, and you'll be helping millions of people have a more secure online profile.

Please indicate whether you'd be willing to publicly endorse this library when the issues you've filed have been fixed. I'm looking for top security experts to sign off on the security of this library.

Thank you for your help!

Sincerely,

Eric Elliott Author, "Programming JavaScript Applications" (O'Reilly) & "Learn JavaScript with Eric Elliott" (online courses)

[ericelliott]

If you can find a security flaw and prove it with reproducible tests, I'll give you a Lifetime Access Pass to my "Learn JavaScript with Eric Elliott" courses, including a free autographed copy of "Programming JavaScript Applictaions".

[ericelliott]

Does your business depend on Node apps? Consider offering a cash bounty to add to the Credential prize. Make your apps more secure, and get some sponsorship exposure, as well. =)

[matthiasak]

createSalt = function createSalt(keyLength, callback) {
    crypto.randomBytes(keyLength, function (err, buff) {
      if (err) {
        return callback(err);
      }
      callback(null, buff.toString('base64'));
    });
  },

You will need to validate that crypto's PRNG is also "secure"

[ericelliott]

Thanks @matthiasak - any tips on how to do that? Is there a test suite we can run against it?

[brianmhunt]

@matthiasak Do you mean to say the RNG must be a CPRNG?

It'd help to have a link to the Node.js / io.js source.

[matthiasak]

@ericelliott @brianmhunt

I'm not sure of a test suite, but I'm sure we can find some proof of both the code's existence, and proof that the PRNG is indeed cryptographically secure or sufficiently random enough.

We'd have to do some digging for that. :D

[rightaway]

I researched all of the libs I could find and found serious security flaws in all of them

Could you please describe the problems you found with the widely-used bcrypt module? It's what I'm currently using and would like to evaluate switching to credential, thanks.

Wondering as I also came across http://security.stackexchange.com/a/6415 which says bcrypt, while not perfect, is somewhat better than pbkdf2.

[ericelliott]

I am not aware of any fatal flaw of Bcrypt.

The main reason I chose PBKDF2 over Bcrypt is that at the time, there was more security research available for PBKDF2.

However, the way that most people are using Bcrypt does not allow for a variable work function, which means that as the application ages, passwords become ever more vulnerable to brute force CPU attacks. If you use Bcrypt, make sure that you're including a way to grow work units over time.

[rightaway]

make sure that you're including a way to grow work units over time

Any standard or recommended way to go about this?

[ericelliott]

Any standard or recommended way to go about this?

There is no standard that I'm aware of, but the time it takes to compute should double every two years to keep pace with Moore's law.

[brianmhunt]

@rightaway Here's an on point SO question – Recommended # of iterations when using PBKDF2-SHA256?, and parallel question on Security.SE Recommended # of iterations when using PKBDF2-SHA256?. Those questions have excellent answers, IMO.

The general advise is "as many as you can tolerate". You're probably looking at 300,000 plus nowadays to stay ahead of the curve.

Another alternative is passwordless authentication. The biggest player going down that road right now appears to be Yahoo.

[ericelliott]

:+1:

Also, big vote for passwordless auth. If hackers manage to steal your db, they can distribute cracking work across hundreds of thousands of pwned server nodes, which would obviously put a bit of a damper on your keystretch strategy, even if you have a high work value. );

Even with the recommended 300,000 iterations, hackers with large botnets and direct access to your db could run half a million tests per second -- too slow to be a serious threat to truly secure passwords, but fast enough to mount a dictionary-aided tests against a huge majority of commonly used passwords.