Need Password Security expert endorsement

[ericelliott]

Need Password Security expert endorsement

[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]

👍

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.