I am currently working on the migration of a user Identity and Access Management tool from a legacy platform (product + solution) to a new one (same product but upgraded + updated solution)

My team was challenged with the following requirements:

  • users should keep the same password
  • users should keep the same challenge questions & answers

We believe that as a best practice users should setup new password and new challenge questions & answers.

Also, we need to ensure compliance with GDPR, which means we are avoiding procedures and files that may show in plain text sensitive data.

What is the standard here?

  • What is your reason for wanting to reset users passwords and questions, other than the plain-text concerns? Mar 8, 2018 at 18:14

2 Answers 2


Assuming the previous authentication system was secure, there shouldn't be a problem with preserving the password and challenge Q&A data. If you feel the previous authentication system was insecure in any way, you can feel free to assume the passwords may be compromised and force your users to reset their passwords on next login.

You mentioned "avoiding procedures and files that may show in plain text sensitive data.". If you're passwords are currently available in any way by plain text, then yes, you should have your users reset their passwords, after implementing a secure authentication process of course.


I can see where your concern with the migration is coming from, however it is slightly misguided.

In fact, user database migrations between IAM and authentication providers are commonplace.

Let’s start with the GDPR mandate.

There should be no way for any external threat actor to access the data of your users on either side. And, if they did it would be useless because your hashing algorithm is not available to them.

Despite the fact you comply with this ruling, your team could theoretically access this database of users and extract them in plain text at any time, just by virtue of having access to your environments and knowing any encryption keys.

As such, a migration creates no new threat of breached PII.

How to achieve this?

So, if your team or the vendor have some way to know the salt/hash mechanism from (a), you should be able to use that as a secondary mechanism on (b) and migrate the encrypted list of users (passwords and all) in the new solution.

And If we assume the following:

  • Your team will act with integrity
  • Any vendor will act with integrity
  • You do not expose the data to the world (S3 bucket) during migration...

You should be good to go!

Actuating the change

At a high level I can think of a couple options such as a csv export, database migration or a script to pump through your existing DB and update each record in the upgraded solution.

My personal preference would be to do a complete DB migration to the upgraded solution, then a separate change to migrate the hashing mechanism.

I suggest engaging that vendor for their suggestion on how to best approach this.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .