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.
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.
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.