Or maybe introduce them to Little Bobby Tables
Or maybe introduce them to Little Bobby Tables
(skeletor is leading by example by adding that unnecessary apostrophe...)
You're viewing a single thread.
While on the topic, this isn't how passwords work in systems.
Passwords are stored as one way hashes. So it's cryptoed only in one direction, it's lossy, and can't be recovered back to the original password.
When you log on, your cleartext PW is hashed in ephemeral memory/storage and then the cleartext password is thrown away.
That hash is compared to the hash in the DB. If the hash matches, then you have access. If it doesn't, then your PW is incorrect.
It's now how passwords work in good systems
And there are plenty of bad systems, especially in this fail fast BS paradigm clueless idiots like to use. We know because they keep getting hacked (looking at you, lastpass!)
Yes, I'm a waterfall guy - get off my lawn!
Permanently Deleted
Sure, but the comic isn't talking about legit password usage systems. It's talking about how a comma could break the csv formatting of a csv file that came from a data breach and dump.
That's still not how it would work.
Ok, assuming that we're talking about, like you say, a system that gets a breach which is storing PWs in clear text/plain text, instead of hashing it, which is a big if as those kinds of systems are either amateur/homebrew, or extinct at this point, but I digress. Let's say it's there.
The attacker would run a sanitization script out of the SQL table that would shift those problem characters into proxy characters, or correct them if it's going to cause a problem. One or two passwords lost to correct for thousands isn't a big deal. The result of trying to put some sort of SQL Injection or CSV formatting bug into your password, hoping it was stored as plaintext, and the attacker wouldn't be sanitizing the common formatting issues, is just silly.
Plus, it's not like they're only exporting it once. They've usually copied the DB down locally, so they'll see the formatting is skewed when parsing the CSV, and correct it on the next export out.
I'm all for the humor here, I was just calling out that nothing about the ideas the OP suggested would work in real life SecOps scenarios.
Souce: Am engineer at large corporation. Deal with scenarios and systems like this all the time.
Edit: People are downvoting this, seemingly because they don't like that the answer makes the OP's joke less funny and pretty unlikely. This is why it's difficult and frustrating to have these kinds of conversations on Lemmy or reddit. I am an expert. I responded with additional information to correct some misunderstandings. It gets down voted because...?
cryptoed
Unless you were looking for a sick rhyme for tiptoed, try encrypted.
Encryption is inherently reversible though. Hashing is the most accurate term to describe it
You are correct.
No, I mean Crypto libraries.
The field of science and engineering that has the algorithms and libraries we would need to use to perform a proper one way encrypted hash, is going to be found in a cryoptographic library.
I suspect you're thinking of Crypto in how it's applied colloquially in the world today with a cryptographically signed linked-list ledger. There's a whole world of cryptography that's in use. Encryption is just one sub-function in that world.
While on the topic, this isn't how passwords work in systems.
Passwords are stored as one way hashes. So it's cryptoed only in one direction, it's lossy, and can't be recovered back to the original password.
When you log on, your cleartext PW is hashed in ephemeral memory/storage and then the cleartext password is thrown away.
That hash is compared to the hash in the DB. If the hash matches, then you have access. If it doesn't, then your PW is incorrect.
Oh my sweet Summer Child. This is definitely how it's supposed to work, but there are plenty of services that just don't know what the fuck they're doing.
Have you ever been on a site that has a stupid-low character limit for a password? There's literally no reason to do that, all the hashes are going to end up the same size in the DB anyway regardless of the original string length. Even
bcrypt's max secret character limit is 70-something characters.Ever change a password and have it not work on the next login because they're silently truncating it after a certain character limit? Ever get an email with an actual password in it?
The only reason you would do things like this is if you're storing/processing passwords in plaintext and not hashing it client-side first.
I can think of 3 offenders of this off the top of my head. It's a lot more common than you'd think.
Even if it's hashed, some systems still use unsalted MD5 which is effectively just as bad as plain text.
I don't understand it. Argon2id has been around for nearly 10 years at this point, scrypt for 15, PBKDF2 for 20 and bcrypt for 25. It's not hard.