Base iteration count on current year.

[ericelliott]

Base iteration count on current year.

[tjconcept]

I'd rather not expire my users passwords, but in stead just silently replace hashes with stronger ones
on log in. I think this has to be handled in user land. Something along the lines of:

1. fetch user from storage
2. verify
3. if hash i considered outdated, save a new hash from cleartext password

[ericelliott]

For safety, password should expire periodically, anyway. Not frequently, but annually isn't terrible.

[ericelliott]

Both those password update options should be out-of-scope for this library, anyway, since they really have nothing to do with password hashing and verification, and everything to do with your UX. Detecting that the password is out of date should be enough to get the ball rolling.

[tjconcept]

Yes, but that is the responsibility of the application IMO.

I propose a method such as "expired(hash, threshold) -> bool"
Is there maybe a better word than "expired"? Something stating; this hash could be better.

A threshold and a more-than-annual increase would be nice to avoid having all users upgrade at 01.01.2016 00:00:00 on the same server each hour ;-)

[tjconcept]

Well, you said it. We were actually more on the same page than I realized.

[ericelliott]

👍

How about "untrusted" instead of "expired"?

[ericelliott]

Want to take a crack at a PR?

[tjconcept]

Would love to, will try to squeeze it in this weekend.

[ericelliott]

Awesome. 👍

[calebboyd]

It seems that if there isn't an explicit iteration count included with the hash, so there would need to be either a year or created field added so that the hashes can be calculated and compared. This was my concern in #9.

[tjconcept]

I've seen #9, and I think the iteration count should be stored as well. I think this is what scrypt does as well (https://github.com/barrysteyn/node-scrypt).

[ericelliott]

I'm willing to ditch the hidden work unit modifier in favor of storing the year in the hash.

[ericelliott]

Go ahead with the breaking change. I think that basing iterations on the current year is much more secure than the security by obscurity in the "hidden" iteration count. ;)

[tjconcept]

Awesome.
The stored hash should IMO be independent from the implementation such that you can freely update/enhance the implementation without invalidating the whole database.

[tjconcept]

I think #14 should be solved first/independently as this seems more like a smaller enhancement to the "determine iterations"-logic.
But I'll happily have a crack at it all in the weekend.

[ericelliott]

Sounds like a great plan. Thanks! 👍