Anakin discovers the dark side of password management
Description
A four-panel meme using the 'For the better, right?' format with Anakin Skywalker and Padmé Amidala from Star Wars. In the first panel, a proud Anakin says, 'I configured the database to store login passwords!'. In the second panel, a smiling Padmé replies, 'You mean the salted hash, right?'. The third panel shows Anakin with a blank, silent stare, implying he has no idea what she's talking about. In the final panel, Padmé's smile has vanished, replaced with a look of dawning horror as she repeats, 'You mean the salted hash, right?'. A watermark for 'imgflip.com' is in the bottom-left corner. This meme hilariously captures a terrifyingly common scenario for senior developers: discovering a junior engineer has implemented a critical security feature (like password storage) in the most insecure way possible - storing plaintext passwords. It highlights the fundamental importance of security practices like hashing and salting to protect user data from breaches
Comments
25Comment deleted
Storing passwords in plaintext is the technical equivalent of writing 'please rob me' on your server's welcome mat. At least with a salted hash, you make them work for it
If your schema still has a `password` column instead of `password_hash`, congrats - you just provisioned both user auth and the future breach post-mortem in a single DDL statement
The real horror isn't finding plaintext passwords in production - it's discovering they're stored in a VARCHAR(20) column because 'nobody needs passwords longer than that' and the senior who wrote it is now the CTO
When your junior dev proudly announces they've 'optimized' authentication by storing passwords in plain text for 'faster lookups,' and you realize your next sprint will be entirely dedicated to explaining why SELECT * FROM users WHERE password = ? is a resume-generating event, not a feature. Bonus points if they've already pushed to production and you're now speedrunning GDPR violation bingo
Plaintext passwords in the DB? That's just a SELECT * FROM breach waiting to happen
Salted hash, right? If your strategy is SHA-256 plus one global salt and the “pepper” in an env var, congrats - you’ve built seasoned plaintext
Nothing says 'enterprise security' like a VARCHAR(255) password column and a Jira ticket titled 'hashing - post‑MVP.'
Where do you keep the salt - hard coded, in database or using characters from username? Comment deleted
Salt is typically part of the output of the password hasing function. On Unix-like platforms this is handled by crypt() standard library function and most modern password hashes mimic it's interface. It uses random string by default and it should be as random as possible unless you have a good reason to make the output more predictable. (Postgresql has decent crypt library built-in by the way) You may be thinking of pepper which is extra step done in application to prevent leaking too much info in case someone gets raw access to SQL server, possibly via command injection. Comment deleted
Wait, isn't salt a part of the input of hash function? Comment deleted
Yes, if you are verifying you need to produce the exact same output. If you are generating new hash though it should be random/unpredictable. The library usually handles that for you. Comment deleted
Salt? Unpredictable? Again someone on internet doesn’t understand difference between salt and pepper! Comment deleted
Yes unpredictable. It was designed to defeat precomputation attacks. Comment deleted
It should be predictable, man. It shouldn’t be used by anyone else. E.g. userEmail + userId Good salt Very predictable Comment deleted
how will you check the password if the salt was unpredictable, lol Comment deleted
Store it in the crypt() format https://en.m.wikipedia.org/wiki/Crypt_(C)#Key_derivation_functions_supported_by_crypt Comment deleted
I know salt but what's pepper? Comment deleted
Part added to hashed data which must be kept in secret (salt - public and easy to found, stored directly in DB or there are clear alghorthm how to get it) For pepper there shouldn't be way to found it, except known by user (e.g. manually written stirng additional string) Comment deleted
Not added to hashed data, added to prehash data Comment deleted
Added to data before it is hashed, sure, otherwise there is no reasob to to do) Comment deleted
I've always thought that it's a password to symmetric encryption of the hashes, that could be regularly changed Comment deleted
No, salt isn’t required input for hash function Comment deleted
Can someone send a blank template for this? Comment deleted
google my friend Comment deleted
Nice advice Comment deleted