TL;DR: In the past, it was standard practice to require that users follow a link in an email to migrate their password to a new system. Now administrators are hesitant to take up any more of their users’ workday than necessary. Fortunately, automating the password-hash migration process is relatively easy to accomplish in all modern development environments.
DBAs generally don’t like requiring that users reset their passwords. But sometimes a security upgrade or other major system change entails migration of hashed passwords.
When this happens, many admins don’t hesitate to require all users to re-register on the new system via a link sent to them via email. That’s the approach recommended in a four-year-old post on Webmasters Stack Exchange.
Today DBAs have many options for migrating password hashes without requiring any effort by users apart from logging in. The transparent approach relies on retaining the old password in the new system just long enough for each user to verify it when they sign into the new system for the first time.
A simple example of this password-migration approach is described in a Stack Overflow post from January 2013:
Variations on the hash-migration theme for Linux, PHP, others
Password migration is an important concern when considering whether to adopt a new platform. For example, supporters of the Discourse open source discussion system have devised a password-migration plug-in that stores the original password hash in a custom field.
The first time the user signs in with what the new system considers an incorrect password, the original hash method is used to calculate and compare the hash with the stored value. When there’s a match, the “new” password is set automatically and the original hash is cleared.
Password migration is presented as a three-step process in a September 17, 2014, post on the Ole Aass site. First, create a table called users_migrate that has three columns: id, username, and password. Next, execute a query on the server that copies the id, username, and password data from the original user tables into the new table.
Run a query on the server that copies the user values from the original tables to the new password-migration table. Source: Ole Aass
Of course, it’s also possible to overthink the problem. In a post from February 2013 on Stack Exchange’s Super User site, someone pointed out that if there aren’t that many users, it might be fastest to copy the hashes to the new system manually, one-by-one. Someone else recommended the chpasswd tool, and a third person suggested using lastlog to generate a list of users and then grep:
To migrate password hashes in Linux, generate a list of users with lastlog, and then grep them in /etc/shadow. Source: Super User
An even simpler approach to password management and other database-migration tasks is to take advantage of the simplicity and efficiency of the Morpheus database-as-a-service (DBaaS). Morpheus lets you provision, deploy, and host MySQL, MongoDB, Redis, and ElasticSearch databases from a single dashboard.
With the Morpheus DBaaS, you can invoke a new instance of any SQL, NoSQL, or in-memory database in seconds, and each instance is deployed with a free full replica set, in addition to automatic daily backups. Visit the Morpheus site to create a free account.
