One thing shown in the data is that a lot of the reasons behind re-platforming are common but notably, user experience isn’t even on this list.
Customers should be affected as little as possible by a re-platform.
It should be considered another opportunity for positive customer experiences.
Within the re-platforming development process there are a common set of problems These revolve around Data Migration, Integrations, Re-engineering Complex Functionality, and Authentication.
And of these, Authentication is the most complex.
Without jumping into the deep end of Authentication, let’s outline the basics: Authentication is required for you users to access content specific to them, or that require some privilege to access.
This is typically done by identifying a customer, via username or email, and comparing their password with one you have stored for them, typically hashed.
Simple, right?!There’s very limited choice to free stock images for ‘password’, but it’s definitely better than ‘hash’.
Often the issues arise around hashed passwords.
Most frameworks hash differently for their own reasons.
Many hashing algorythms are available but that’s probably suited to another article.
Aside from a strong hashing algorythm a good strategy is to use a password salt.
A password salt helps mitigate rainbow table attacks — A lot of the time this process is abstracted from developers, so it’s understandable if you’ve not come into contact with that before, and to reiterate this is the briefest overview.
Re-platforming often means that the existing hashed password data is useless.
It’s incompatible with the new algorythm, or salt, or something in between.
All of the examples from here on in are using the PHP framework, Laravel.
The general concepts can be applied anywhere.
Initial StrategyWhat is the best way to get your entire user base to reset their passwords?There are a number of technical issues associated with this question, but one significant one is that generating new passwords that contain good quality hashes is quite programmatically expensive.
This leads to the following questions:Invite users en masse?Invite users in groups?.And if so, How do you group people?Invite users to create new passwords as they attempt to sign in?When these options are presented, none of them spark joy, but the final option is likely the best — It has the least impact on performance (as new passwords are generated as and when), and it doesn’t highlight to user that action is immediately required.
It only affects the users who interact with the functionality to begin with.
At the most simple level, there are potentially three areas that are affected: Importing account data from your old platform (if you’re importing from an old platforming rather than using the old database), and when validating a User’s password, or generating a new password hash.
Let’s begin with importing:When a user is imported, there’s no need to import their password, as it needs to be changed.
An empty string in the password hash field is used instead.
We have our users imported, and in our database and we know which ones require a new password (because they have an empty string as a password hash).
When looking at authentication of a user, it’s easy to identify which require a password reset as their hash field will be an empty string.
For an empty hash a 401 Authorization header is returned.
According to RFC-7235 — An expired password is an invalid password and must not be accepted by the server.
If they already have set a new password, the hash field will be populated and this logic will proceed to validate them.
Improving This StrategyWouldn’t it be far better if customers didn’t have to reset their passwords at all?.Can this be done without creating a lot of complexity?Yes.
and Yes!Import the old hashed password and, for convenience, add a flag to the user model indicating that it’s using an old hashed password.
Now on import, users have a password — it’s their old hashed one — but that data is there.
Next we’re going to do something disgusting.
The old framework hashing function has been implemented in the new framework.
(Do it on the proviso that there’s a schedule to remove it when all, or a significant amount of, users are transitioned to new passwords, to make you feel better).
As a user authenticates, if they have the old-hash flag then we validate the authentication by using the old hashing function.
The $credentials variable follows the styles of Laravel’s existing Auth methods, such as attempt(), which takes an array of key/value pairs.
Once confirmed, the hash is regenerated using the new method and the user’s password, and the old-hash flag is removed.
This process, while more complicated, is more amiable from a User perspective.
There is no requirement to reset their password.
In any re-platform there are a numer of obsticles to overcome, of which Authentication.
During this process customers have been a primary concern which was should always be a concern.
A re-platform is a scenario that shouldn’t impact customers in any negative way and through careful thought, a simple yet effective solution has been put together.
Keep your users happyUsers of a service can often be forgotten in these types of technical situations.
Indeed, the message of this article isn’t around the techniques used but more the attitude towards users of a platform.
Considering their experience is paramount, and should be a discussion each and every time — Keep your users happy and enjoying your service without making them jump through hoops when you change things behind the scenes!.. More details