If you decide to keep the backwards compatibility, try making the best out of a bad situation: You will have to make a choice here about what requirements to fulfill. The security requirements forces you to drop them. The compatibility requirements forces you to keep the old hashes. Is there a secure way to add salt (and pepper) to our authentication database while maintaining the old application's ability to authenticate users? Keep in mind that while the old application is inherently insecure it will not be accessible outside of our intranet, the new application however will be.
Remembear salted hash code#
As the code is very much legacy and we don't even have a working compiler for it anymore changing the code of the original application is out of question. The problem here is that this will break the authentication in our old application. This means our database table would get a third field salt and the password field now stores our salted and peppered hash. We decided that part of our modernization is that password policies are put in place and that passwords are stored both salted and peppered. I voiced several concerns regarding security as this application is about handling personal details of my coworkers and me. We are supposed to reuse the current database for authentication purposes to allow both applications to run in parallel on the underlying same authentication database. This application shall be accessible from the wide open internet. Our team is tasked to modernize these services by offering a new application following best practices and lessons learned of the last 15 years (and potentially more that were ignored in the original application).
The password is stored as an unsalted hash.Īn over 15 year old application uses this database to authenticate access to its services. The table has two fields: username and password. I have a MySQL-Database with a table of users. I am presented with the following scenario:
0 kommentar(er)
