My main problem with passwords is the limits that sites put on what I can set for a password.
I could not tell you how many times I reset my password using my password manager, then immediately log out, and log in using the credentials I just saved into my password manager, and they don't work, because the site is truncating the password to 15/20/whatever characters.
The number of times this limitation is not clearly stated, checked for, or even acknowledged by the site is too damn high.
I've made it a habit of testing a login after every password set/reset to ensure I don't have trouble with it in the future.
The amount of websites that limit passwords to 16 characters is alarming
I created an account on a hosted service we use at work the other day, my password had to be exactly 12 characters. No more no less.
Wow, that's an extra level of special.
Stored plaintext in a CHAR(12) field in a DB2 database.
Usually 15, 16, 20, or 25 in my experience.
15/16 I get, no idea why 20/25 is so common.
My password manager generates 32 character passwords composed of random alphanumeric characters by default. I usually don't modify it unless I hit a restriction, or its a site I'm particularly concerned about getting penetrated (in which case I increase the number of characters).
I don't mind sharing that because bluntly: anyone reading this, good luck figuring it out. The permutations is something along the lines of (26*2+10+(special characters))^32... Which is 3.5239... * 10^60... Otherwise known as 3.5 novemdecillion.
Ha.
Wish we just had like 256 char passwords so I could actually use passphrases instead of passwords.
It'd be way more secure for me compared to what I'm doing now.
I'd do like Star Trek haikus or some such which would be actually possible to remember.
A person of culture, I see.
For spice, I randomly change my password length. 15 to 50+. I don't even fucking know.
My fucking bank: ๐
ALL banks.
Or when the app has different limits than the webpage!
See also: Sites that don't allow "+" in email addresses while logging in, but do accept them at registration (including confirmation emails)
Funny, but csv values are quote encapsulated and special character escaped.
Common CSV parsers don't require it and I've seen plenty of examples of unquoted CSV cells (which, given there's no actual standard for the format, isn't too surprising). Hell I've created my fair share while throwing together ad hoc datasets. The idea that some of these dumps might be made by folks who are too careless to properly quote and escape their CSV data isn't hard to believe at all.
A classic example of naive CSV encoding is joining a bunch of floats with commas while using a locale that has a comma for a decimal point.
I had a dota2 bug where all of the maps particle effects would spawn in the middle. Yep, a locale dot/comma thing.
When you're lucky your data provider has high standards.
The CSV cells are escaped with quotes. So just maybe throw some quotes in too. Unbalanced for style points. It won't defeat a CSV library, but might break a script kiddie
Unbalanced for style points.
I like the cut of your jib. End it with a single backslash, for good measure.
If you include ;",// you can mess with a wide variety of formatting.
'; DROP TABLE `passwords`; --
My bank doesn't allow the characters you would need for a SQL injection in passwords.
Checked client side, I don't want to try and find out if it's also checked server side, but I hope it is.
No serious software would fall for such an easy attack anymore. With prepared statements it's impossible to break queries like that. Beside that one principle is to avoid using user inputs directly in your database.
Good way to punish websites that have zero security i suppose
"comma's"?
"COMMA'S"?!
There was a (really short-lived) shady car dealership that used to have an A-Frame sign that they mustโve paid to get printed.
It said โYour approvedโ.
My approved?
I imagine someone mustโve mentioned it to them, because they replaced it not much later.
The new sign said โEveryones Approvedโ.
My approvedOUR approved.
I hate when when people misuse apostrophe's
Use a password like MARCH1 so that Excel will change it when the data is loaded.
Thanks! just set that as my Lemmy password
I only see it as *******
Strange, it shows up as MARCH1 for me
๐คฃ๐คฃ๐คฃ
That seems horribly insecure
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.
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!)
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
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.
Remove apostrophes from your plural words, they show possession, not plurality.
Until next time.
It's there intentionally as part of an injection attack
Woosh?
No, I don't think so.
LOL
I do think so
Can you add a "TAB" into a password?
\t is your best shot. For good measure, you'll also want to add double quotes (can be used to escape commas in CSVs), double double quotes, back slashes, and |s, just to mess with anyone trying to sanitize a CSV with your password in it.
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 to enter the character without triggering any "move to next field" behaviour. In *nix it should be Ctrl+I.
Similar with other control characters - NUL (0) might be harder to type, yet substantially more likely to break things!
SHY is good if you'd like a character which can't be seen, without needing to resort to Unicode.
If webpages are storing plain password and not the hash, we should be worried
Don't worry. I make sure to Sha1 encrypt them first.
Yo, why no love for md5?
We contract for a regional bank and we use a Vigenรจre cipher to store passwords
Ave Caesar! We attack at midnight.
I wrote my own password manager about a year ago, in java. It uses Vigenรจre encryption using a key the computer doesn't remember (that you have to write down somewhere). I still don't actually use it in my daily life, firefoxes password manager is pretty convenient and I'm pretty lazy...
By the way (you're quicker than duckduckgoing) Are you able to view and export password in plain text if you want to discontinue using the firefox password manager?
I've resisted using password managers up to this point, but it's getting to be a pain
Yes, I think so.
You can definitely view them in plaintext,
And you can export them, too.
Sha1 hash do you mean? Sha1 is just a hash algorithm.
No, no. It's perfectly safe I assure you.
If webpages are storing plain password and not the hash, we should be worried
Yes.
Hi kind reminder password hashes.
For all no-tech-people: what? Please explain
If you're a company, you should save your users' passwords as "hashes" which is like a scrambled up version, so if your data gets stolen the hackers will have to unscramble all the passwords which takes a long time. Some naughty companies don't do this and save their passwords as plain text. The person above is presumably talking to developers to remind them not to be naughty
I'm saying that password dumps are usually hashed passwords anyway, so there won't be commas just base 64 along with usernames and other stuff that probably doesn't contain commas.
For the benefit of the person above you, thats not to say that hashed passwords are unbreakable, because hackers can build a thing called a rainbow rmtable where they hash a bunch of known passwords, words, and phrases, and then can compare their rainbow table agains a stolen hash to learn what the starting value might have been. Thats why a complex password is very useful
Not much of an Issue thanks to salting
Only if you dont make the salting or hashing wrong which happens far to often
From many years of experience on the interwebs, I can recommend this password:
It's very secure and works most of the time. I use it for everything.
Just changed my password to this, thanks!
hunter2
Wow, what a coincidence, my password is ******* too!
hunter2 isn't a very strong password โ personally I use ************.
IRC is leaking again...
You clearly don't use this one, don't you know lemmy instances automatically censor your ********?
Censor your what? Your ********?
What's all the commotion? I'm pretty sure you can say ********, no?
Oh cool - how does it know?
Hunter2
Yeah, mine is removed.
Just added this to my brute force dictionary thank you ๐
Can you take it out again? I still want to use this. Thanks.
I dunno. If I was the asshole running the script that broke at whatever line your user was in. I'd take special care to fuck with you right back. ;)
No you don't. I checked ;)
What's it say? All I see is *******************.
While you're adding commas, learn how apostrophes work.
That's not an apostrophe, it's a comma floating away.
S-H-comma to the top-Dynasty
Did you hear about Pluto?
I use it to signify "here come's an S!"
Don'st.
I u'se it to 'signify "here come's an 'S!"*
Dave Barry FTW!
You mean apostrophe's.
And it's not even consistent. Why is it "comma's," but not "password's"?
Maybe they're Dutch, there it's only done for words that end in a vowel. Probably not though.
Interesting, didn't know that!
I think it's a Greek root so surely it's apostrophedes.
My main problem with passwords is the limits that sites put on what I can set for a password.
I could not tell you how many times I reset my password using my password manager, then immediately log out, and log in using the credentials I just saved into my password manager, and they don't work, because the site is truncating the password to 15/20/whatever characters.
The number of times this limitation is not clearly stated, checked for, or even acknowledged by the site is too damn high.
I've made it a habit of testing a login after every password set/reset to ensure I don't have trouble with it in the future.
The amount of websites that limit passwords to 16 characters is alarming
I created an account on a hosted service we use at work the other day, my password had to be exactly 12 characters. No more no less.
Wow, that's an extra level of special.
Stored plaintext in a CHAR(12) field in a DB2 database.
Usually 15, 16, 20, or 25 in my experience.
15/16 I get, no idea why 20/25 is so common.
My password manager generates 32 character passwords composed of random alphanumeric characters by default. I usually don't modify it unless I hit a restriction, or its a site I'm particularly concerned about getting penetrated (in which case I increase the number of characters).
I don't mind sharing that because bluntly: anyone reading this, good luck figuring it out. The permutations is something along the lines of (26*2+10+(special characters))^32... Which is 3.5239... * 10^60... Otherwise known as 3.5 novemdecillion.
Ha.
Wish we just had like 256 char passwords so I could actually use passphrases instead of passwords.
It'd be way more secure for me compared to what I'm doing now.
I'd do like Star Trek haikus or some such which would be actually possible to remember.
A person of culture, I see.
For spice, I randomly change my password length. 15 to 50+. I don't even fucking know.
My fucking bank: ๐
ALL banks.
Or when the app has different limits than the webpage!
See also: Sites that don't allow "+" in email addresses while logging in, but do accept them at registration (including confirmation emails)
Funny, but csv values are quote encapsulated and special character escaped.
Common CSV parsers don't require it and I've seen plenty of examples of unquoted CSV cells (which, given there's no actual standard for the format, isn't too surprising). Hell I've created my fair share while throwing together ad hoc datasets. The idea that some of these dumps might be made by folks who are too careless to properly quote and escape their CSV data isn't hard to believe at all.
There actually is a standard, it's just no one cares.
Oh, so it's like USB cords. Or basically any other technology standard.
Someone never disappoints by linking this one.
A classic example of naive CSV encoding is joining a bunch of floats with commas while using a locale that has a comma for a decimal point.
I had a dota2 bug where all of the maps particle effects would spawn in the middle. Yep, a locale dot/comma thing.
When you're lucky your data provider has high standards.
The CSV cells are escaped with quotes. So just maybe throw some quotes in too. Unbalanced for style points. It won't defeat a CSV library, but might break a script kiddie
I like the cut of your jib. End it with a single backslash, for good measure.
If you include ;",// you can mess with a wide variety of formatting.
'; DROP TABLE `passwords`; --
My bank doesn't allow the characters you would need for a SQL injection in passwords. Checked client side, I don't want to try and find out if it's also checked server side, but I hope it is.
No serious software would fall for such an easy attack anymore. With prepared statements it's impossible to break queries like that. Beside that one principle is to avoid using user inputs directly in your database.
Good way to punish websites that have zero security i suppose
"comma's"?
"COMMA'S"?!
There was a (really short-lived) shady car dealership that used to have an A-Frame sign that they mustโve paid to get printed.
It said โYour approvedโ.
My approved?
I imagine someone mustโve mentioned it to them, because they replaced it not much later.
The new sign said โEveryones Approvedโ.
My approvedOUR approved.I hate when when people misuse apostrophe's
Use a password like MARCH1 so that Excel will change it when the data is loaded.
Thanks! just set that as my Lemmy password
I only see it as *******
Strange, it shows up as MARCH1 for me
๐คฃ๐คฃ๐คฃ
That seems horribly insecure
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:
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.
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!
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...?
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.
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.
Security advice: Just use URLs/links as password. Until next time!
Can someone help me understand this? It seems interesting.
Long string of effectively random (in terms of their connection to you) words + special characters that make it hard to either guess or brute force.
Thanks, I now use This as my password for all my important information.
Here is an alternative Piped link(s):
This
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I'm open-source; check me out at GitHub.
Remove apostrophes from your plural words, they show possession, not plurality. Until next time.
It's there intentionally as part of an injection attack
Woosh?
No, I don't think so.
LOL
I do think so
Can you add a "TAB" into a password?
\t is your best shot. For good measure, you'll also want to add double quotes (can be used to escape commas in CSVs), double double quotes, back slashes, and |s, just to mess with anyone trying to sanitize a CSV with your password in it.
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 to enter the character without triggering any "move to next field" behaviour. In *nix it should be Ctrl+I.
Similar with other control characters - NUL (0) might be harder to type, yet substantially more likely to break things!
SHY is good if you'd like a character which can't be seen, without needing to resort to Unicode.
If webpages are storing plain password and not the hash, we should be worried
Don't worry. I make sure to Sha1 encrypt them first.
Yo, why no love for md5?
We contract for a regional bank and we use a Vigenรจre cipher to store passwords
Ave Caesar! We attack at midnight.
I wrote my own password manager about a year ago, in java. It uses Vigenรจre encryption using a key the computer doesn't remember (that you have to write down somewhere). I still don't actually use it in my daily life, firefoxes password manager is pretty convenient and I'm pretty lazy...
By the way (you're quicker than duckduckgoing) Are you able to view and export password in plain text if you want to discontinue using the firefox password manager?
I've resisted using password managers up to this point, but it's getting to be a pain
Yes, I think so. You can definitely view them in plaintext, And you can export them, too.
Sha1 hash do you mean? Sha1 is just a hash algorithm.
No, no. It's perfectly safe I assure you.
Yes.
Hi kind reminder password hashes.
For all no-tech-people: what? Please explain
If you're a company, you should save your users' passwords as "hashes" which is like a scrambled up version, so if your data gets stolen the hackers will have to unscramble all the passwords which takes a long time. Some naughty companies don't do this and save their passwords as plain text. The person above is presumably talking to developers to remind them not to be naughty
I'm saying that password dumps are usually hashed passwords anyway, so there won't be commas just base 64 along with usernames and other stuff that probably doesn't contain commas.
For the benefit of the person above you, thats not to say that hashed passwords are unbreakable, because hackers can build a thing called a rainbow rmtable where they hash a bunch of known passwords, words, and phrases, and then can compare their rainbow table agains a stolen hash to learn what the starting value might have been. Thats why a complex password is very useful
Not much of an Issue thanks to salting
Only if you dont make the salting or hashing wrong which happens far to often
This terminology is making me hungry
Tl;dr: parseley, hash browns and salt is good.
So
What about semicolon?