The capability for rehashing passwords is something probably most customers will want to use in DS 7. The configuration surrounding rehash-policy could be improved:
- Due to defaults and other adjustments, the setting for the default password policy rehash-policy:always is different from the others rehash-policy:never. This is generally invisible to the admin because rehash-policy is advanced, and therefore hidden by default.
- The default of never does prevent the admin from accidentally cratering performance when changing the bcrypt-cost or pbkdf2-iterations. But because the rehash setting is hidden by default, and because nobody ever reads the docs first, the admin is likely to be wondering why changing the cost or iterations setting has no effect. A more secure default would be rehash-policy:only-increase. Admins who unthinkingly increase the cost and then are stunned when performance craters can always roll back the change.
- In order to help admins, the information about rehash impact could be included in the description of bcrypt-cost and pbkdf2-iterations. For example, "By default, increasing this setting causes the server to recalculate each user's password hash on their next authentication, and write the new hash to the user's entry on disk. Changing the number of iterations therefore leads to a short-term spike in CPU and disk use as the server updates each user's password when they next authenticate. Longer term, increasing this settings results in more secure passwords at the expense of longer response times and lower throughput." This would show up in online help and in interactive sessions.