4

I have a system with a few thousand user accounts that I need to migrate to a new platform. The system stores a hashed password, not encrypted or (thank goodness) plain text. Also, I don't have the details of the hashing readily available.

What are some effective ways to make the transition? One idea comes to mind off the top of my head:

  1. Ahead of time, I can migrate all the data. Current users in the old platform will have an account and all their data in the new platform.
  2. Rip out some of the code that currently handles authentication and turn it into a kind of service that will check the validity of the username/password.
  3. The new platform can first check it's own authentication to see whether the password has been transferred. If it hasn't, it could call the service on the other platform to determine whether it's valid in the old system.
  4. If it's not valid, then it tells the user their login was wrong.
  5. If it is valid, it now knows the correct password and can populate its own user table with the password (according to whatever scheme that platform uses).
Improve this question

2 Answers 2

Reset to default
3

I went through a similar issue recently except I didn't have access to the hash algorithm that was being used. I think you have 2 choices.

  1. Move all of the user profiles over to the new system and have an extra column with their old password hash.
  2. When the user logs in for the first time your system will see no account exists in the new system but a hash exists from the old system. Your system will keep a pre-hash copy of the password and check the hashed version against the old hash.
  3. If the old hash matches set the password in the new system to what they sent in.

However, if you find you don't have access to the hash algorithm and you have each users email address you have another choice. This is what I did actually:

  1. Copy over all of the usernames, email address, and info from the old to the new system. Put a flag column in the table denoting the user is from the old system.
  2. When the user logs into the new system for the first time, the new system will see that they have an account but have no password.
  3. Have your system put a message on the screen saying something like "We have updated our website and your user account has been converted. You will receive an email shortly with a new temporary password(make sure the password or special link works for only a short period of time).
  4. Send the user a temp password to your new site that will let them log in. Once they log in for the first time have them reset their password to whatever they like.

The second option worked pretty well for me. I had virtually no user complaints and it is relatively secure since that is the normal process for a user to reset their forgotten password.

Improve this answer
1

Before you go though too much trouble, have you looked into what the hash algorithm might be? If they were sane enough to use hashed passwords, hopefully they were sane enough to use a common hash algorithm (MD5, SHA1, etc).

Might be worthwhile to try out a few common options to see if you can reverse-engineer what they were doing.

Also, you mention "ripping out some of the code that currently does authentication". How is it that you have the code, but not the hash algorithm?

Improve this answer
4
  • Common hash algorithm are often salted you have to be careful with that.
    – HoLyVieR
    Jul 16, 2010 at 17:33
  • Good question. Attempting to reverse-engineer is an option on the table. The old platform is a heavily abstracted ColdFusion site. I can fairly easily see the code in the presentation layer that calls "PlatformObject.Authenticate(username,password)", but I haven't found the actual hashing mechanism. I probably could find it, but I could get away with just using the higher level function.
    – Larsenal
    Jul 16, 2010 at 17:47
  • @HoLyVieR - Yes, but the salt has to be stored somewhere. It could be hard-coded into the code, but that's almost as insecure as not having a salt at all.
    – Eric Petroelje
    Jul 16, 2010 at 18:31
  • hardcoded salt is still better than none, because it makes collision attack on the hash value harder. Also, static value like username are used as salt, this isn't something that you might see at first when looking at the code and the data, but you need to keep in mind that such system exists. Imagine if you migrate the hash without knowing they are salted, nobody will be able to login.
    – HoLyVieR
    Jul 16, 2010 at 19:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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