On the other hand, if you go out of your way to pollute the data and the hacker debugs the resulting errors and finds you as the culprit, they may target you as a form of petty revenge.
In R, libraries will often tell you when there is a parsing anomaly and which line it occurs with. The first thing I do is examine those lines closely!
Having special characters is a good idea but having a comma just to break a CSV is dumb. This would only happen if the hacker used a bad exporter or created their own (very poorly).
AFAIK it's only "ambiguous" in the sense that if you get a csv file you can't determine the exact parsing behavior to use, but if you know what program created the csv (or what encoder options were used), it's not ambiguous to parse.
>but things get really hairy really fast when you start adding types or BLOBs in the CSV.
AFAIK BLOBs are hex encoded, which make them a non issue.
comma being a very common and probably common when many organization are enforcing special character policy . For those big exports , they are probably not dumping out as csv , it would be light weight db file . I assume sqllite
Yea good assumption, SQLMap for instance, defaults --dump to .csv with sqlite as an option if you're just looking for a simpler test point. Plenty of other tooling options out there too. Tooling providing your encoding during dump will overcome the ',' concern though, no?
True - a friend of mine worked in a dangerous part of the world and was car-jacked in a manual car. As soon as the car-jacker was behind the wheel they realised they couldn't drive the car and gave up.
My brother had a stick shift. Kids broke into his car and proceeded to drive it 15 feet into a pole and abandon it. Whole thing was caught on camera too.
But can’t the hacker just write a small function to fix that? If I found a comma in the third position in a hash crack I might assume it’s part of the password and not a column separator.
Have you ever used quotes in a password. I did. IOS was constantly changing quotes into smart quotes. Super annoying for those times when I had to actually type in my password.
The reason you might want to put such character in a password is not in case it might leak, but in order to break the idiotic system which stores and handles those passwords in plain text. I would use a double quote and a single quote. That will break things if passwords are wrapped in quotes without escaping.
PRO TIP: You can also use % to punish incorrect use of printf(3), $ to punish use of "eval" in Perl and bash, <> to break HTML parsing, * to punish overzealous filename globbing, & to set off forkbombs on the unsuspecting victims, +++ATH0 to make their modems hang up, and ! to prevent transmission via UUCP.
And then back into a corner, splash a can of paint in every direction, put your head between your knees, and wait for WWIII. (If it doesn't start by the time the paint dries, do it all over again tomorrow.)
On the other hand, if you go out of your way to pollute the data and the hacker debugs the resulting errors and finds you as the culprit, they may target you as a form of petty revenge.
In R, libraries will often tell you when there is a parsing anomaly and which line it occurs with. The first thing I do is examine those lines closely!
[dead]
Alternatively, include mojibake in your passwords so attackers think they have a unicode encoding bug
In case anyone else doesn’t know mojibake: https://en.wikipedia.org/wiki/Mojibake
I prefer to use zero-width joiners in my passwords and usernames to really give db dumpers a fun time.
Hackers will often dox someone they are very annoyed with, and it sounds like this is a good bait for that.
Include a few control characters for good measure.
In my experience, nothing says fun times in a data dump like null ‘characters’!
[dead]
These people will be shocked to learn about escaping
I always use both a comma and a semicolon. Just to cover more bases.
Seeing posts linked to my little mastodon instance is feels so strange, in a good way
Having special characters is a good idea but having a comma just to break a CSV is dumb. This would only happen if the hacker used a bad exporter or created their own (very poorly).
Yeah, this is silly. Pretty much every serializer in existence is going to handle this case. If the attacker wrote their own, then you might get lucky
AFAIU CSV is fundamentally ambiguous and can't actually be parsed in a fully deterministic way.
Edge cases get hard when dealing with nested commas, and there's no standard escape sequence.
Probably matters less with a two column arrangement, but things get really hairy really fast when you start adding types or BLOBs in the CSV.
AFAIK it's only "ambiguous" in the sense that if you get a csv file you can't determine the exact parsing behavior to use, but if you know what program created the csv (or what encoder options were used), it's not ambiguous to parse.
>but things get really hairy really fast when you start adding types or BLOBs in the CSV.
AFAIK BLOBs are hex encoded, which make them a non issue.
Hah! Half the time people will even do silly things like cat together multiple CSVs from different sources.
If blobs got consistently hex encoded, that would also be nice. Base64 is common, and there are multiple types of base64 encoding people use too.
Personally, I tend to think of CSV imports as something you can expect to have a ‘yield’ - and it’s never 100%.
yea so just do BSV or bell separated file. We already have "\n" newline separated files. We just need a cel seperator, '\b'. Problem solved.
On the plus side, accidentally cat’ng it to your terminal will be pleasantly musical.
comma being a very common and probably common when many organization are enforcing special character policy . For those big exports , they are probably not dumping out as csv , it would be light weight db file . I assume sqllite
This is why all my passwords have '); drop table passwords; somewhere in there.
Yea good assumption, SQLMap for instance, defaults --dump to .csv with sqlite as an option if you're just looking for a simpler test point. Plenty of other tooling options out there too. Tooling providing your encoding during dump will overcome the ',' concern though, no?
[]https://highon.coffee/blog/sqlmap-cheat-sheet/#sqlmap-dump-d...
Any competent CSV parser will see straight through that.
It's to force simplistic dumpers produce invalid CSVs.
I alternate between infrared and ultraviolet salts to foil rainbow tables
Any purple salt will be immune as it's not found in the rainbow.
What does that mean?
https://en.wikipedia.org/wiki/Salt_%28cryptography%29
HN and Toot look robust, considering all the comments with separator examples. Perhaps some comments were detected and rejected.
Always drive a stick shift, no young person will be able to steal your car.
True - a friend of mine worked in a dangerous part of the world and was car-jacked in a manual car. As soon as the car-jacker was behind the wheel they realised they couldn't drive the car and gave up.
My brother had a stick shift. Kids broke into his car and proceeded to drive it 15 feet into a pole and abandon it. Whole thing was caught on camera too.
Always pull the fuel pump fuse before leaving your car, then no one can ever even drive your car.
I had a friend who's clutch switch failed. Like most cars, it wouldn't start because it couldn't detect that you'd depressed the clutch.
He added a toggle switch under the dash instead of fixing the clutch switch. He figured it'd be some poor man's anti theft.
I think it would have worked. It was pretty fun having friends try to move his car for a while.
i’m surprised a link to a toot which is just an incorrect meme no longer than the title of the submission itself would get upvoted here
The HN title is 77 chars, the linked post is 98 chars. If you're going to criticize something about the post at least be correct in your assertions :P
77, 98 - what's the difference when you write 135 complaining about it? ;)
how dare you
But can’t the hacker just write a small function to fix that? If I found a comma in the third position in a hash crack I might assume it’s part of the password and not a column separator.
Use quotes too then!
Have you ever used quotes in a password. I did. IOS was constantly changing quotes into smart quotes. Super annoying for those times when I had to actually type in my password.
","
break it, but not in a way that throws a parse error
What about \""\t\n"?
I like to have some variation of ":(){ :|:& };:" in most of my metadata somewhere ..
The reason you might want to put such character in a password is not in case it might leak, but in order to break the idiotic system which stores and handles those passwords in plain text. I would use a double quote and a single quote. That will break things if passwords are wrapped in quotes without escaping.
PRO TIP: You can also use % to punish incorrect use of printf(3), $ to punish use of "eval" in Perl and bash, <> to break HTML parsing, * to punish overzealous filename globbing, & to set off forkbombs on the unsuspecting victims, +++ATH0 to make their modems hang up, and ! to prevent transmission via UUCP.
And then back into a corner, splash a can of paint in every direction, put your head between your knees, and wait for WWIII. (If it doesn't start by the time the paint dries, do it all over again tomorrow.)