Or maybe introduce them to Little Bobby Tables
Or maybe introduce them to Little Bobby Tables
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.
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!
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 encrypting 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.
cryptoed Unless you were looking for a sick rhyme for tiptoed, try encrypted.
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.
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.
Yes, char(9) is the SQL string for it.
However most modern password attributes are blocking this from SQL injections where a playfully named user “Drop Table” does not cause any harm
Of course. In Windows you can hold Alt and type 0 0 9 before releasing the Alt key.
Similar with other control characters, although NULL might be harder to type yet more likely to break things.
SHY is good if you’d like a character which can’t be seen without using unicode’s hidden characters.
From many years of experience on the interwebs, I can recommend this password:
NUL,\t.;TAB\n\x07^C
It’s very secure and works most of the time. I use it for everything.
Oh cool - how does it know?
Hunter2
The CSV specification (RFC-4180) is pretty clear. If a value contains commas, you wrap it in double quotes. If the value contains double quotes, you double each double quote to indicate its part of the value and not the end of the value.
A properly formatted CSV should have no problems from Skeletor!
There’s no formal spec for CSV. The RFC you mentioned describes the most common behaviour observed in many implementations, but it’s not a spec itself, as mentioned on the second page:
While there are various specifications and implementations for the CSV format (for ex. [4], [5], [6] and [7]), there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files. This section documents the format that seems to be followed by most implementations:
Also, my understanding is that double quotes are only used for strings. Commas can appear outside of strings, for example in numbers in countries that use them as a decimal point. That’s actually why many implementations use semicolons or tabs as the separator.
So
'"\tpassword\t