3

We are migrating some users to a new database from a legacy app's database and have written a script to pull the users and all their data from an existing database.

As the user's passwords are hashed we cannot pull these, which is fine, however before we get them to perform a reset I was just wondering what the safest way to do this would be:

  • Make the password field NULL and populate the field on reset
  • Generate a random password for the user, leave the password field as NOT NULL and populate on reset

Generating a random password seems like extra, unnecessary work however I'm thinking having a NULL password might be a security hole as under normal circumstances all users would have a password, so this would never be NULL.

Can anyone offer some guidance?

  • 1
    Is an empty password parsed as NULL by your system? – schroeder Apr 20 '17 at 15:48
  • Do you mean an empty string? This would just be an empty string, rather than NULL. – Mike F Apr 20 '17 at 16:37
  • 2
    Because I'm curious, why aren't you able to migrate the passwords (I assume you mean hashed, rather than encrypted)? You do not necessarily need the clear text. Are you changing to a new hashing algorithm? – Dan Landberg Apr 20 '17 at 17:33
  • Do you know what the current hashing scheme is. Makes a big difference – ste-fu Apr 21 '17 at 20:11
7

Import the existing password hashes along with the rest of the data, add a 'dirty bit' flag to the new database and set it to true for these imported users.

When the user goes to login have it validate using the hash mechanism that was used in the legacy app/code, then force the user to update their password using whatever the current method is, store the new hash, and turn off the flag.

Bit more work on the back-end but if you take the time to set it up right it makes any future switches easier and makes it much smoother for the end user to transition.

Edit: Plus, you avoid the potential (read as surefire) mess that is setting a user's password to NULL or blank. How is anyone supposed to verify that the end user is the 'actual' user?

| improve this answer | |
4

The question here is, how your login logic interprets an undefined value in place of a the password hash. I assume you mean NULL in the SQL sense, as an undefined value.

If the system compares the hash of the user-entered password with the stored hash, as it should, then an undefined value (or even an empty string) would never match. Similarly, the stored hash could be set to some other string that will never match as a valid password hash. On Linux systems, you can see system accounts in /etc/shadow with a * in the place of the password hash, and locking a user with usermod -L sets the hash to !. Neither of those is ever a valid password hash so logging in with a password will not succeed.

However, if there is a risk that the login system would interpret an undefined (or empty) value as matching an empty password, you'd seriously want to avoid using them. An undefined value could also lead to an error, which in the least might not look nice.

You would need to check that the system is known and tested to work with undefined passwords, or if there is some other way to mark an account as unusable or locked. Generating a valid hash matching a randomly-generated long password that is not stored anywhere would be safe in that the system is likely to be able to handle that in any case.

| improve this answer | |
  • Nice answer! One detail: Instead of storing the hash of a random password, I would suggest using a random hash. Might not actually be a printable password that corresponds to the hash, but since its not supposed to be used it doesn't matter. – Anders Jun 20 '17 at 23:10
  • 1
    @Anders, yeah, you could do that too. In theory a system could be really picky about the password hash format, and generating the hash from a password the usual way should be safe even without knowing anything about the system (even the hash used). Probably not a likely problem in a sensible system. – ilkkachu Jun 21 '17 at 10:39
1

Why not just migrate the passwords hashes as well if you are going to generate random password anyways? You can then either force people to change password on first login if you keep the old hash algorithm or do what even you are planning to do with random/null passwords now if you don't keep the same hash algorithm.

Unless your passwords were plain text/extremely poorly hashed before, I don't see why the third option of just migrating hashes would be a problem.

| improve this answer | |
1

I personally would tend to favour the 'random password per user' approach, since there is otherwise a chance accounts could be 'stolen' by simple virtue of being the first person to try and log in with a given username.

This would though require that users are made aware of the migration, so that the email with the new password and new URL (or whatever the case might be) doesn't come out of nowhere.

However, when you say your current password are encrypted, what exactly do you mean?

If they are hashed rather than encrypted, then I would tend to think it might be worth working out how they are hashed, and simply pull them with the other data.

When a user logs in for the first time, you can then either:

  • force a password change, and hash the new password with whatever you are aiming to use in your new app
  • or authenticate users with their 'regular' passwords, and if the password check passes, re-hash their password and store it.

Unless both apps were using the same message digest algorithm, a simple check of the stored, hashed password length could tell you which passwords are not using your desired hashing algorithm.

If the passwords really are encrypted, it might also make sense to see if you can find out how they are encrypted, and pick one of the two approaches mentioned above to update your own DB.

| improve this answer | |
-3

I will use NULL is this case, because any string hashed is never identical to NULL, which means there is 0 chance that the user can sign in.

| improve this answer | |
  • This does not answer the question and does not account for the cases brought up by other answers. Primarily, you might not be sure how unexpected inputs might behave and might match a NULL – schroeder Nov 7 '19 at 13:14
  • As long as the library is written correctly it will never match a NULL. – Michael Tsang Nov 11 '19 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.