having hash in logs

[ericelliott]

having hash in logs

[tjconcept]

I am not really an expert on this but my take is: as long as compute power increases, any hash would eventually become vulnerable. That is why you should rehash your users passwords with ever more cycles from time to time. A log containing "old" hashes would entirely defeat this purpose.

If you read some comments on the #16 issue, you will understand though, that all efforts in this regards are, when taking it to a high enough level, obsolete. So one conclusion could be; as passwords are inherently weak, the vector from computers getting faster is too small in comparison to care about (things like educating users is better "real security"-per-time-wise).

Anyway, if you have the option to avoid them in the logs, I would say do that.

[ericelliott]

Avoid logging anything password related.

[maxlath]

thank you for your answers. One thing I'm not sure to get right is how iterations are control: when Thomas, you say hashing with ever more cycles, how do I control that with credential? There is no parameter for that right? Will the future releases progressively increase iterations in the default hash function?

[tjconcept]

There is no parameter for that right

Yes there is; work and it has an initial value of 1. You can double the iteration count be setting it to 2, making you hashing take twice as long.

Will the future releases progressively increase iterations

It does so already: https://github.com/ericelliott/credential/blob/master/credential.js#L96-L100
The number of iterations increases every second making each new hash slightly stronger than the previous.

You'll have to implement the code to do the actual updating of current hashes yourself though (e.g. when a user logs in, because you need the clear text password), and that is what the expired method (https://github.com/ericelliott/credential/blob/master/credential.js#L111-L116) is for.

Be aware that the current release on npm does not include these last to features though, and that work parameter was called workUnits and had an initial value of 60.
I hope we get a new release soon though (see #24).

[maxlath]

oh, right, in the configure method. Thanks for the tips!
Two ideas for the readme:

• adding a statement for new comers on the level of trust we can have in default settings, like, is there a need to use the configure function at all for a "normal" app
• a statement or an example illustrating where this configure function should be called: I guess right after the require('credential'), but is it affecting the configuration in all the application or just in the current module?

[ericelliott]

a statement or an example illustrating where this configure function should be called: I guess right after the require('credential'), but is it affecting the configuration in all the application or just in the current module?

This is a good question, and reveals a bit of a design flaw in the current version of Credential. Normally, when you require something, you get a singleton. Since the .configure() method directly changes this and there's no particular instance, options are likely to be application-wide.

This could be easily corrected by making credential a factory (as is the case with all the default Express middleware, and Express, itself).

I think we should do that for the next version.