From Spring Security 5, there is DelegatingPasswordEncoder which enables supporting different encoding algorithms in the same field.
For example, if you migrate from SHA to Bcrypt, your password fields will look like the following.
Column name: password and there are three rows.
|password|
|{bcrypt}$2b$12$FaLabMRystU4MLAasNOKb.HUElBAabuQdX59RWHq5X.9Ghm692NEi|
|5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5|
|41911abb01112afcc18159f6cc74b4f51123159b3caf5a9c173cacfc51234512|The prefix {bcrypt} indicates this password is encoded by Bcrypt encoder, and the rest are encoded by SHA, which is the defualt. DelegatingPasswordEncoder detects the prefix {bcrypt} and know this password is encoded by {bcrypt} and can check if the input matches this value. If you want to learn more, I recommend to read https://www.baeldung.com/spring-security-5-password-storage
The reality: the old encoder is Bcrypt(password) and the new encoder is Bcrypt(SHA(password)). Reason: https://medium.com/@sendoh-daten/the-password-disaster-when-migrating-authentication-service-7e792e5d9930
Cannot rollback
The problem I faced is there is a strict rule that every change to deploy needs to be backward-compatible with very littel exception.
When the user signs up with the new version of app, which persists a row with the prefix {bcrypt-sha} in the database, after rolling back the user cannot login , because the older version of the application doesn’t know how to handle {bcrypt-sha}, and only the new version of application knows.
Can rollback
At the end, two password encoders are used at the same time. One field `v0` is inserted by the old version of encoder and the other field `v1` is inserted by the new version of encoder. When the app needs to roll back, the old version of the app can still work with the `v0` field.
If your app doesn’t support password yet, don’t support password. You can save the time and effort which is what I would recommend.
