2.1k
u/as-if-spike 19d ago
663
19d ago
[removed] — view removed comment
228
u/Kihino 19d ago
Security nerds hate this one simple trick
61
→ More replies (1)71
u/A1oso 19d ago
It wasn't compliant before if the passwords were stored in plain text.
50
u/ItWearsHimOut 19d ago
Could be hashed, but unsalted.
47
10
u/Procrasturbating 19d ago
Had to teach my team about salts when I saw similar ratios of reused passwords. Wild. Billion in revenue a year.. and I see it company after company. No cares until there is a breach.
3
u/Theron3206 19d ago
Theres a salt, its just the same one for every password (that how it's supposed to work right).
3
160
u/Kihino 19d ago
Why stop there when one can use semantic vectors instead of hashes, only store cluster averages and then do similarity matching instead of equivalence checks. Will bring storage way down and have the added benefit of not requiring you to know which exact version of your default password was used, as long as you get the gist of it!
124
u/DERPYBASTARD 19d ago
That sounds complicated, we can just approve every login attempt
66
48
u/Tupcek 19d ago
that is too easy for scammers.
Log them in only if they enter same password three times. That means they are fairly confident it’s their password
16
u/Auravendill 19d ago
Great, we can just do the check client side and save a lot of server and bandwidth load.
18
u/ellamking 19d ago
I am currently out of the office until October 3rd and will be unable approve any login attempts until that date. Sorry for any inconvenience that has caused.
Betty
5
u/LaconicLacedaemonian 19d ago
That's a bit risky. Let's add a flag we can trusted=true clients set with each api call to certify they are only valid traffic.
3
u/yarntank 19d ago
Why make the trusted clients do the work? Make a policy that non-trusted clients use the evil bit.
https://www.rfc-editor.org/info/rfc3514/https://www.rfc-editor.org/info/rfc3514/
9
u/YeOldeMemeShoppe 19d ago
``` Hey Claude, does this password match your memory? “$1”
Only answer Yes or No. ```
4
u/Key_Big1051 19d ago
I have Zero idea what I read
17
u/Kihino 19d ago
Imagine an AI looking at passwords and determining whether they mean the same thing. Eg Hunter2, hunter2, HuNtEr2 all have the same meaning, albeit different spelling. This meaning can be represented as a vector, and these vectors can be clustered so we say a user has simply a password that is essentially “something like hunter”. When a user types in their password, you can then check if that password is indeed “something like hunter”. If so, you admit them otherwise reject it.
12
u/Armond436 19d ago
It's been 22 years and hunter2 is still going strong. Bless.
11
u/ProfessorLambda 19d ago
"*******" is going strong? What does that mean? Did you censor your own post?
→ More replies (2)11
u/almostcleverbut 19d ago
The real savings comes from no longer having to ask them for a username... just have them type the password and choose the most likely user account based on the password's semantic similarity score.
Ties are randomized to defeat distinguisher-based attack methods, obviously
3
5
u/YeOldeMemeShoppe 19d ago
Think of how Shazam matches songs, but for passwords. “Close enough” is the answer to the algorithm.
4
u/aammirzaei 19d ago
read about vector database / embeddings it's got really popular recently becuase llms and ai
2
→ More replies (2)2
371
u/Chiccitynotess 19d ago
On the bright side, your database deduplication metrics look fantastic right before the data breach lawsuit
1.1k
u/braytag 19d ago
If you have 100GB of password, you have other problems.....
333
u/Totendax12K 19d ago
the HIBP databse is around 40gb with 1bil+ hashed passwords
214
u/Penki- 19d ago
Then OP in picture must work in Meta on Facebook. Checks out
→ More replies (3)117
5
→ More replies (1)2
u/Physmatik 19d ago
If you have enough users to fill 40GB of password you probably don't care about 10 extra bucks per month of maintenance.
→ More replies (1)25
u/therealkevinard 19d ago
Password is your favorite movie.
Upload the dvdrip to register→ More replies (1)20
7
19d ago edited 18d ago
[deleted]
3
u/Noch_ein_Kamel 19d ago
I'd assume it's all plaintext passwords.
3
u/CocktailPerson 19d ago
Plaintext would be smaller because most passwords aren't 32 bytes long.
In other words, you could fit far more than 3 billion plaintext passwords in 100GB.
3
u/beastrabban 19d ago
Store each char of the password as a separate string variable and connect them using a custom linked list
200
u/Flat_Initial_1823 19d ago
Why use big table when default password do trick
37
185
u/Lamborghinigamer 19d ago
That also means that they don't use salting or even worse store everything in plain text 😨
83
u/silmelumenn 19d ago
You could do the same but with hashes instead of passwords though
87
u/ReneKiller 19d ago
Yeah, if you are not using salts. Otherwise every hash should be different, even if the password is the same. (Excluding the unlikely occasion of the same hash for different texts).
→ More replies (8)→ More replies (16)28
u/Lamborghinigamer 19d ago
Exactly. Like I said, they don't use salting
7
u/silmelumenn 19d ago
Let's go complex keys (salt, hashcode) 😅
9
u/Lamborghinigamer 19d ago
Exactly. A unique salt guarantees a unique hash every time, so every single user gets a unique row regardless. Deduplicating unique rows with foreign keys is mathematically impossible
15
u/DrDeform 19d ago
If they really wanted to reduce storage then they can do the no passwords and every login requires a temp email code. Those sites really piss me off.
5
u/PlasticExtreme4469 19d ago
Or they misunderstood the purpose of salt and reused it for every password.
2
u/Kymera_7 19d ago
Nah, they're using a random number generator for the salt. They bought it from the company Dilbert works for.
3
u/PixelatedGiant 19d ago
I'm so glad modern hashing algorithms include a random salt within the hash. People used to do it so wrong. You're supposed to create a salt per password, not use a single global one.
→ More replies (1)2
43
u/reubenbubu 19d ago
Allowing password reuse is a security concern that can be avoided with an easy validation step:
The password you provided is already in use by user /u/NoMedicine3572. Please choose a different password.
33
u/TgirlTiffanyRPs 19d ago
Can someone explain the joke? Why wouldn’t you store (hashed/salted) passwords in one table ?
59
u/ninjakivi2 19d ago
The joke is that these password are not salted, and each unique password will be given an ID. Then, under the user table you will store the ID reference to the password, instead of the password. This means that if 2 users use the same password they will have the same ID and only be stored once, saving space.
→ More replies (10)25
u/Winsaucerer 19d ago edited 19d ago
They could be salted, just not with a per password salt. Which is much less useful, but does still make rainbow table attacks harder.
10
17
u/Great-Powerful-Talia 19d ago
If they're salted, the space saved here is minimal.
There's only lots of duplicate entries (from 2 people using the same password) if they're stored unsalted or in plaintext.
Which is exactly why they need to be salted.
→ More replies (1)12
8
u/tekanet 19d ago
If you have users using password “letmein” (eventually hashed, but not salted), instead of a Password column you can have a PasswordId column referencing by foreign key the record in the Passwords table that contains said password. Since most users choose the same password, you end up with less space used by the foreign key column.
It doesn’t make sense on different levels, but that’s the gist of it.
3
u/amejin 19d ago
It's not the storage of salted passwords that's the problem, it's the shared state via reference.
How do you handle password changes? You also reduce the footprint for attack. 200k uniquely salted passwords are much harder to crack than 500 shared passwords with the same salt.
If we're being fair, though, if someone is reading your rows like this you've already been compromised and leaking email/pw combos is low on your list of problems.
2
→ More replies (1)2
u/laplongejr 18d ago
(hashed/salted) passwords
"Users are reusing passwords anyway"
There's not an ounce of salt in there.
30
u/FalconFiveZeroNine 19d ago
As a DBA who works with devs a lot, I gave up trying to keep them from doing things. They just kick their requests up the corporate ladder until they get their way. Then a few months later it blows up and I get blamed for it.
10
u/DooMRunneR 18d ago
stop trying to prevent it and make it cost something instead. when devs want something dumb, write down the actual risk in the ticket, not just "this is bad" but what breaks and how. if they escalate and get it approved anyway, whoever approves it signs off on the risk with their name on it, plus who owns support when it blows up and when it gets reviewed again. if its a real architecture thing pull in your EAs and get an ADR for it
tbh the paper alone wont save you if your company loves blaming people. what actually helps is sorting out ownership before it goes live. dev team pushed it through? then they get paged at 3am when it falls over, not you. funny how many "super urgent" requests dissapear once someone has to put their name on it and carry the on call for it
27
u/bilus 19d ago
Doesn’t math
7
5
u/ttttrrrr0000 19d ago edited 19d ago
It could, an int FK is 4 bytes, and the table of passwords would be 4 bytes PK + 16 bytes for the unsalted hashed password
So, about 50% larger if everyone's password is unique, and 75% smaller if everyone's password is the same. Breakeven point is at the ratio of 3 unique passwords per 5 people.
→ More replies (2)3
12
11
10
u/LogicBalm 19d ago
Gotta enforce security policy though. Unique passwords and extensive password history.
"invalid password, that password is already in use by user witty_kitty69"
4
6
u/Jazoboz 19d ago
WTF is a salt?? I like my passwords raw!
4
u/blindedtrickster 19d ago
Unseasoned passwords? Sir, I'm afraid we're going to have to ask you to leave.
2
→ More replies (1)2
u/BackgroundRate1825 19d ago
I think we can pepper in some puns if you've got the thyme.
→ More replies (1)
8
u/I_HAVE_THAT_FETISH 19d ago
Just take the password and run it through an algorithm to calculate a salt that hashes it to a pre-determined string!
6
u/-Redstoneboi- 19d ago
sounds computationally expensive. besides, why even store a password? just derive it by hashing the email address with the account creation timestamp and ask the user to save it
2
u/I_HAVE_THAT_FETISH 19d ago
We support password managers, so if the user wants to generate a new password for themself we can regenerate their salt to hit the same fixed hash. That way, if they happen to forget the date of account creation, there's still an option for recovery.
Although... For your method, if the user forgets their password we can generate an entirely new account, which boosts user engagement metrics, so it will probably go over well with management.
3
u/Rikudou_Sage 19d ago
Good idea, that way you can actually control the storage growth! Got some VC funds? Just change a single number in your algorithm and you get more password hash space!
7
u/seanprefect 19d ago
Security architect here, I’m dead now, my heart and head exploded I’m writing this via spiritual medium
6
u/heesell 19d ago
Just send a password to the user their email with each login. No DB storage needed
3
u/2nd-Reddit-Account 19d ago
This is actually a thing, without even bothering with the password.
I use a few services where passwords have been replaced with being emailed a log in button on each sign in attempt, clicking the button in the mail opens a new tab of the site with you logged in.
It’s like sign in with google, but universal across all email providers and domains
→ More replies (1)
11
u/Stummi 19d ago edited 19d ago
I am not a DB engineer, but wouldn't a good database engine deduplicate multiple identical strings in a table by itself?
E: I know, its not working if you account for per-user salts, please don't take this too serious
25
u/Pingumask 19d ago
There should be no duplicates. You're supposed to salt the passwords before hashing them to avoid making it visible that two users have the same password to anyone accessing the DB (even to someone with legit access to the DB)
6
u/Historical-Silver495 19d ago
Help, I'm not a programmer. After salting the passwords I realized I overdid it, can I use something to counterbalance it like sugar?
→ More replies (1)7
10
u/flingerdu 19d ago
If you have duplicate password strings you have a whole lot of other problems besides using a few additional MB of disk space.
→ More replies (1)3
u/RavenX86 19d ago
I’m pretty sure fb stored passwords in plain text for years, I wouldn’t worry that much
→ More replies (2)5
→ More replies (3)2
3
u/Available_Canary_517 19d ago
Even if password are same , the generated hash is different with a salt so it is useless because you introduced a extra join without any improvement
7
u/CadenVanV 19d ago
I don’t think someone doing this shit is hashing or salting their passwords to begin with
→ More replies (1)
3
u/Future-World1780 19d ago
Just don't store passwords at all and simply let the user pass the login at the third attempt.
5
4
u/ora00001 17d ago
100 GB to 3GB is not a result of password reuse. That's something else terrible going on.
3
3
u/Glum_Cheesecake9859 19d ago
Even better.
if (password == 1234) {
loginUser();
}
this will save 90% of DB hits.
3
u/CoolCat1337One 19d ago
he is talking about password hashes, right?
2
u/Rikudou_Sage 19d ago
You people and your hashes... Just do it like a man and store it unhashed. Or use reversible encryption if you're a pussy.
→ More replies (2)2
u/laplongejr 18d ago
The whole idea of a random salt is that password reuse wouldn't lead to more collisions in hashes...
→ More replies (4)
3
u/henryeaterofpies 19d ago
I think this gave me an aneurysm and I am not a dba, security or sys admin
3
3
u/mittfh 19d ago
Bonus points if the passwords are stored in plaintext...
...on the same machine as the external Web server...
... Which, naturally, uses http (not s)...
... And the Admin/Root password is in one of the "Top 100 passwords exposed by data breaches" lists ("Password123" and friends). 😈
4
u/CLOWNFLOGGER 19d ago
I just write mine under the brim of my Yankees hat, like every other responsible Gen X dude.
3
u/CDavis10717 19d ago
Retired DBA Mgr here. I’ve had security audits where an auditor sat next to me, told me what db tools to use, what tables to select and screen cap, paste the caps into an email to them and sent it, all in their presence.
This overly normalized password management method will never pass a true security audit.
→ More replies (4)
2
u/ICantBelieveItsNotEC 19d ago
A SQL database isn't going to scale. I suggest creating a new Password Service microservice backed by DynamoDB that allows the User Service to upset and retrieve passwords by ID.
3
2
2
2
u/Randy191919 19d ago
How many users do you need to have have 100GB of passwords?
→ More replies (2)
2
2
u/BungalowsAreScams 19d ago
My company just barely fixed the fact that we were required to have a password be exactly 8 characters long and they weren't even case sensitive for one of our internal tools. Idk how something ends up like that
2
2
u/PrometheusMMIV 19d ago
You have over 97 GB of passwords? Even at 12 characters, that's over 8 billion users. And that's just the repeated ones.
→ More replies (1)
2
u/North_Affect_8167 19d ago
Make a selection of 3 allowed passwords and forget about the whole database thing, the most users should use 2-factor auth anyway.
2
2
1
1
u/norwegian 19d ago
They probably means hashes, bc storing passwords is a lawsuit waiting to happen.
1
1
1
4.9k
u/Away_Advisor3460 19d ago
Pff, amateur hour.
If you really want to save space, don't store any passwords. Just require the same string to be entered three times in a row. If the user re-types the exact same value after being told it's wrong twice, the must be confident enough in it to be a legit user - nobody is going to enter the same value 3 times if they're trying to guess a password.