Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API

From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Related Rants
Story: Password hashing and UTF-8
Context: PHP 5.6, 270kloc 15+ years legacy project. ~3 years ago. tl;dr at bottom.
Password hashing & verification was done with an obsolete way of hashing passwords. I was given the task to update our password handler to from now on generate passwords with PHP's good built-in password hashing function.
It was decided that old passwords still needed to work, instead of prompting users to set a new password. The old password verification still had to function in conjunction with the new.
The previous password handler was split into multiple classes, due to (I assume) poor structuring and shoehorning in an object oriented approach. Furthermore, it abused global variables.
A new password handler had to be created.
I implemented the new password verification and creation methods (which now used PHP internal password functions), and it worked perfectly. Then to get the old password verification to work.
I removed all obsolete methods from the old handler, and was left with a hashing function which took in a password, salt, and a secret key. I copied this code into the new handler.
It failed. It returned "Password does not match" for old passwords. I was unsure what had happened here. I did all sorts of shotgun debugging. I ended up with two versions of the login page next to each other, which used the old and new code respectively. I started modifying the original code, extracting variables, logging, you name it. I ended up with exactly the same snippets of code in both password handlers, and yet it failed.
The culprit? The character encoding.
Because this project was over a decade old, the .php-file had the encoding 'windows-1252'. When I created the new password handler, my IDE set the file encoding to 'UTF-8'. Then when I copied the secret, my IDE converted the string to 'UTF-8', effectively changing the value of the secret and causing any password verifications to fail. The solution was to manually create a string using the byte values in the old secret.
<rant>
It is these extreme, obscene, scenarios which makes working with legacy projects a living hell. In this scenario, it was my IDE at fault for changing the character encoding.
But my IDE is not the root problem. No, I blame it on the lack of maintenance from previous developers. Not keeping the codebase up to standard causes problems like this in the long run.
</rant>
tl;dr: copied hash secret to a file with another encoding. IDE changed the byte values for those characters, causing password verification to fail. fml.
rant
passwords
encoding
hell
hash
5.6
legacy
php