Comment by RajT88
2 years ago
I once argued with a senior dev (later engineering manager, I guess he is a director of development now somewhere), that storing password hashes in unsalted SHA1 was bad.
His defense? "This system is internal only and never connected to the internet"
Senior titled devs don't necessarily know their shit.
A little off topic, but I love how you mention his career progression before sharing the example of his ignorance, because this seems to be a pretty common theme in tech companies (I've witnessed it more times than I can remember or count). The people I knew in my career who were most full of shit are pretty much all now Directors and VPs, enjoying a life of success, and the ones who were the most actually knowledgable are still grinding away as IC's, worried about layoffs. This industry is really bad about rewarding competence.
> This industry is really bad about rewarding competence.
If you promote the competent people, you leave the incompetent ones to do the actual work.
The trick then is not hiring bozos in the first place.
2 replies →
Non security expert here. Walk me through the attack scenario here.
The database has access control right? So only a few people in the org can read the data. And you are imagining a case where they:
a) find an inverse image of a password hash and use that login as another person to do something bad.
b) reverse the password from the hash to use in another context.
If a is an issue, why does this individual have sensitive data access in the first place? b is still unlikely. Any inverse image is unlikely to be the password if there is salting.
It sounds like an improvement could be made, but maybe not the highest priority. Can you inform me?