Securely store password reset tokens

As displayed in https://github.com/feathersjs/feathers-authentication-management/blob/master/src/sendResetPwd.js#L37, it doesn’t look like this module hashes the password reset tokens when it adds them to the user’s data store. However, reset tokens are a credential useful to an adversary in the case of a data breach, similar to that of passwords themselves. It is a lot less work to use a reset token to take over a user’s account than it is to brute-force bcrypt hashes.

I think that the reset tokens should be sent, and then the user model patched with the hashed variant of the sent token. This will mitigate a number of situations in which the database can be read (and not necessarily written to) by an adversary. A realistic situation I brought up in a recent blog post is a situation in which the database is directly exposed for reading to the internet due to misconfiguration. An adversary can issue password resets for users and hijack accounts without needing write access to the user models of the applications.

I didn’t issue a PR for this as I’m not entirely familiar with the architecture of Feathers, and it seems that a change of this nature would be a breaking change for existing reset tokens unless the user model was flagged or migrated in some fashion, a non-trivial task when the hashing algorithm and underlying data store can be changed. These are architectural decisions best left to maintainers.

Ways I can see this happening:

1. In new versions of feathers-authentication-management, patchUser also patches user models with isSecureToken: true as a stopgap, and the code branches to check old, active reset tokens. New reset tokens are hashed and checked against the hashed variant.
2. Don’t worry about it. Tokens have a short expiration date, and the token not matching just forces a new reset for some users stuck during the migration process.
3. Migrate old plaintext tokens upon upgrade to the new module. This would likely need some way to detect whether an existing token was hashed, which is fuzzy at best given that the password hash algorithm can be changed out by a user.

[micaksica2]

Does that mean you are indifferent at this stage as to which way it goes? If I’m writing the PR for this I’m going to choose the “break old reset tokens” option because it’s by far the easiest to develop and test for. 😀

[eddyystop]

The a-l-m rewrite has an option.passwordfield. The default is obtained from config/default.json.

Full details at https://github.com/feathers-plus/authentication-local-management/blob/master/misc/upgrading.md