Timeline for Is there a way to add salted hashing to my user authentication without breaking my former login server
Current License: CC BY-SA 4.0
11 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Dec 3, 2019 at 18:40 | comment | added | GrandOpener | It's true that you can't get rid of the problem while the old app is running, but it sounds like the plan is to bring up the new app, run them in parallel until feature parity is reached, and then discontinue the new app. In that case, the answer might be better phrased as "yes, eventually." If I'm wrong and the plan is to run both of them indefinitely, then "no" is absolutely the correct answer. | |
Dec 3, 2019 at 10:10 | comment | added | Frank | @NumLock Yep, that would work, which is the answer below. Not sure why is this marked as the accepted answer as there are several ways of implementing this. | |
Dec 3, 2019 at 9:43 | comment | added | Num Lock |
What about migrating from hash(plain) to hash(hash(plain), salt) ? Just out of interest, as this would break the legacy application.
|
|
Dec 3, 2019 at 8:00 | comment | added | Frank | @R.. agreed but it changes the parameters of the problem. We know now that the problem can be solved, because a password reset does not store plaintext. See my answer below for solution | |
Dec 3, 2019 at 1:06 | comment | added | R.. GitHub STOP HELPING ICE | @Frank: Unsalted with weak hash is, for all intents and purposes, plaintext. | |
Dec 2, 2019 at 23:52 | comment | added | Frank | The op does not say there is any plaintext password. | |
Dec 2, 2019 at 12:34 | vote | accept | Ben | ||
Dec 3, 2019 at 10:31 | |||||
Dec 2, 2019 at 12:25 | history | edited | mti2935 | CC BY-SA 4.0 |
added 21 characters in body
|
Dec 2, 2019 at 12:06 | comment | added | mti2935 | I agree. I think your organization needs to seriously think about updating or replacing the legacy application such that it follows modern security standards. If that is not possible in the near future, then you might want to consider using two separate databases (one for the internal legacy application, with the passwords stored in plaintext; and another separate database for the new public-facing application with the passwords salted and hashed), and running a process that keeps the data synced between the two databases. | |
Dec 2, 2019 at 11:56 | comment | added | Ben | Meaning that as we only hash to make a potential databreach less impactful we are simply opening ourselves up to a way bigger world of hurt by now also having the data accessible over the open internet instead of internally only, making the chance for such a breach to happen in the first place just way more likely, correct? I don't see how this is anything but a massive security disaster about to happen right now... | |
Dec 2, 2019 at 11:52 | history | answered | mti2935 | CC BY-SA 4.0 |