NIST proposes barring some of the most nonsensical password rules
(arstechnica.com)
from Amicitas@lemmy.world to technology@lemmy.world on 26 Sep 2024 01:23
https://lemmy.world/post/20190319
from Amicitas@lemmy.world to technology@lemmy.world on 26 Sep 2024 01:23
https://lemmy.world/post/20190319
Here is the text of the NIST sp800-63b Digital Identity Guidelines.
threaded - newest
A.k.a use a password manager for most things and a couple of long complex passwords for things that a password manager wouldn’t work for (the password manager’s password, encrypted system partitions, etc). I’m assuming In just summed up 35,000 words.
.
Yes.
Eh, no.
It is a boring document but it not impossible to read through, nor understand. The is what compliances officer do. I have a (useless) cybersecurity degree and reading NIST publications is part of my lecture.
My career as a sysadmin consistently has me veering toward security and compliance and my brain is absolutely fried on trying to figure out what these huge docs actually mean, how they apply to the things I’m responsible for and what we’re supposed to do about it.
Props to all the folks that can do it without losing their mind.
You break it down into chunks and delegate. They’re not expecting any one person to implement the whole thing.
Hahaha, tell that to leadership! 😩
You need to first understand the grand structure of the doc, then cherry pick the content to action points. At least that’s how I do it.
Useless??? Ever since the pandemic and the need for a robust remote work infrastructure, the amount of cybersecurity related job offers has exploded. And they’re very well paid where I live.
The knowledge and skill are useful, but I can’t say the same for the degree
My argument is that if this document (and others) are requirements for companies shouldn’t there also be a more approachable document for people to use?
Sure, have the jargon filled document that those in the know can access, but without an additional not so jargon-y document you’ve just added a barrier to change. Maybe just an abstract of the rule changes on the front page without the jargon?
I don’t know, maybe it’s not a big deal to compliance officers but just seems to me (someone that isn’t a compliance officer) that obfuscating the required changes behind jargon and acronyms is going to slow adoption of the changes.
It needs to be specific to be clear for its purposes. You can express everything in simpler terms but then you risk leaving things out of definitions. It’s basically legal speak.
Normally, you’d read the scope of such a document to see whether it fits your purpose, then cherry-pick the chapters necessary. If something’s unclear, you can google pretty much everything.
Doing that a few times will make it infinitely easier! You especially get to understand those broad, inaccessible definitions a lot easier.
Any password length (within reason) and any character should be allowed. It’s going to be hashed and only the hash will be stored right? Length and character limits make me suspect it’s being stored in plain text.
Then you’re vulnerable to simple brute force attacks, which if paired with a dumped hash table, can severely cut the time it takes to solve the hash and reveal all passwords.
By any length I meant no maximum length. Obviously you don’t want to use a super short password.
“What’s your password?”
“The letter A.”
Mine is the null string. They’ll never guess it!
Some kind of upper bound is usually sensible. You can open a potential DoS vector by accepting anything. The 72 byte bcrypt/scrypt limit is generally sensible, but going for 255 would be fine. There’s very little security to be gained at those lengths.
I do 256 so I hopefully never need to update it, but most of my passwords are 20-30 characters or something, and generated by my password manager. I don’t care if you choose to write a poem or enter a ton of unicode, I just need a bunch of bytes to hash.
I don’t know about a min length; setting a lenient lower bound means that any passwords in that space are going to be absolutely brute force-able (and because humans are lazy, there are almost certainly be passwords clustered around the minimum).
I very much agree with the rest though, it’s unnerving when sites have a low max length. It almost feels like advertising that passwords aren’t being hashed, and if that’s the case there’s a snowball’s chance in hell that they’re also salted. Really restrictive character sets also tell me that said site / company either has super old infra or doesn’t know how to sanitize strings (or entirely likely both)…
The only justifiable reason I can see to have a length limit is because longer passwords would take more time to process and they don’t want to deal with that.
Although it would only be on the order of a couple of extra microseconds and I’m not sure how much difference it would really make. But even on cyber security forums the max password length is 64 characters.
But it really doesn’t, unless you’re sending megabytes of text or something. Industry standard password algorithms run the hash a lot of times, and your entry will only impact the first iteration.
I usually set mine to 256 characters to prevent DOS attacks, and also so I don’t need to update it ever. Most of my passwords are actually around 20-30 characters in length (I pick a random length in the slider on my password manager), because I don’t want to be there all day if I ever need to manually enter it (looking at you stupid smart TV…).
That’s exactly what someone malicious would do though, either in a single password submission or DOS via the password maximum repeatedly. IMO there is no functional security difference between a 64 and a 256 character password, so the NIST 64 character max is reasonable.
Rules here are 64 as a reasonable maximum. A lot of programmers don’t realize that bcrypt and scrypt max at 72 bytes (which may or may not be the same as 72 characters). You can get around it by prehashing, but meh. This is long enough even for a reasonable passphrase scheme.
Minor note: 64 unicode characters is potentially much more than 72 bytes.
You should probably have some safeguard to prevent jokers from uploading 14.2 gigabytes of absolute nonsense into your system’s password field just to see if they can make it crash. But I think limiting it to, like, 8 kB ought to be quite lenient for anything with a modern internet connection.
As others have noticed, various hashing functions have an upperbound input length limit anyway. But I don’t see any pressing reason to limit your field length to exactly that, even if only not to reveal anything about what you might be feeding that value into behind the scenes.
I usually do 256 characters. That’s long enough that most password managers top out anyway (mine tops out at 128), and it shouldn’t ever present a DOS risk. Anything much beyond that and you’ll go beyond the hash length.
Reworded rules for clarity:
I was expecting idiotic rules screaming “bureaucratic muppets don’t know what they’re legislating on”, but instead what I’m seeing is surprisingly sane and sensible.
NIST generally knows what they’re doing. Want to overwrite a hard drive securely? NIST 800-88 has you covered. Need a competition for a new block cipher? NIST ran that and AES came out of it. Same for a new hash with SHA3.
Didn’t know about sha3.
For now, at least. Could change after Inauguration Day.
I hate that anyone has to be told not to truncate passwords. Like even if you haven’t had any training at all, you’d have to be advanced stupid to even come up with that idea in the first place.
Can you elaborate further? Why would someone want to truncate passwords to begin with?
To save a few megabytes of text in a database somewhere. Likely the same database that gets hacked.
Which shouldn’t even matter because passwords are salted and hashed before storing them, so you’re not actually saving anything. At least they better be. If you’re not hashing passwords you’ve got a much bigger problem than low complexity passwords.
The place that truncates passwords is probably not the place to look for best practices when it comes to security. :-)
Hashing passwords isn’t even best practice at this point, it’s the minimally acceptable standard.
What is the best practice currently?
Use a library. It’s far too easy for developers or project managers to fuck up the minimum requirements for safely storing passwords.
But, if you are wanting to do it by hand…
Isn’t that… the very definition of a Salt? A user-specific known string? Though my understanding is that the salt gets appended to the user-provided password, hashed and then checked against the record, so I wouldn’t say that the hash is salted, but rather the password.
Also using a pepper is good practice in addition to a salt, though the latter is more important.
Some implementers reuse the same salt for all passwords. It’s not the worst thing ever, but it does make it substantially easier to crack than if everything has its own salt.
That’s a pepper not a salt. A constant value added to the password that’s the same for every user is a pepper and prevents rainbow table attacks. A per-user value added is a salt and prevents a number of things, but the big one is being able to overwrite a users password entry with another known users password (perhaps with a SQL injection).
I remember hearing to not layer encryptions or hashes on top of themselves. It didn’t make any sense to me at the time. It was presented as if that weakened the encryption somehow, though wasn’t elaborated on (it was a security focused class, not encryption focused, so didn’t go heavy into the math).
Like my thought was, if doing more encryption weakened the encryption that was already there, couldn’t an attacker just do more encryption themselves to reduce entropy?
The class was overall good, but this was still a university level CS course and I really wish I had pressed on that bit of “advice” more. Best guess at this point is that I misunderstood what was really being said because it just never made any sense at all to me.
It’s because layering doesn’t really gain you anything so it only has downsides. It’s important to differentiate encryption and hashing from here on since the dangers are different.
With hashing, layering different hashing algorithms can lead to increased collision chance and if done wrong a reduced entropy (for instance hashing a 256 bit hash with a 16 bit hashing algorithm). Done correctly it’s probably fine and in fact rehashing a hash with the same algorithm is standard practice, but care should be taken.
With encryption things get much worse. When layering encryption algorithms a flaw in one can severely compromise them all. Presumably you’re using the same secret across them all. If the attacker has a known piece of input or can potentially control the input a variety of potential attack vectors open up. If there’s a flaw in one of the algorithms used that can make the process of extracting the encryption key much easier. Often times the key is more valuable than any single piece of input because keys are often shared across many encrypted files or data streams.
With the hash one, it doesn’t look like that could be exploited by an attacker doing the bad hashing themselves, since any collisions they do find will only be relevant to the extra hashing they do on their end.
But that encryption one still sounds like it could be exploited by an attacker applying more encryption themselves. Though I’m assuming there’s a public key the attacker has access to and if more layers of encryption make it easier to determine the associated private key, then just do that?
Though when you say they share the same secret, my assumption is that a public key for one algorithm doesn’t map to the same private key as another algorithm, so wouldn’t cracking one layer still be uncorrelated with cracking the other layers? Assuming it’s not reusing a one time pad or something like that, so I guess context matters here.
Sorta. Not really.
Key derivation algorithms are still hashes in most practical ways. Though they’re derived directly from block ciphers in most cases, so you could also say they’re encrypted. Even though people say to hash passwords, not encrypt them.
I find the whole terminology here to be unenlightening. It obscures more than it understands.
A KDF is not reversible so it’s not encryption (a bad one can be brute forced or have a collision, but that’s different from decrypting it even if the outcome is effectively the same). As long as you’re salting (and ideally peppering) your passwords and the iteration count is sufficiently high, any sufficiently long password will be effectively unrecoverable via any known means (barring a flaw being found in the KDF).
The defining characteristic that separates hashing from encryption is that for hashing there is no inverse function that can take the output and one or more extra parameters (secrets, salts, etc.) and produce the original input, unlike with encryption.
OK. How do you reconcile that with “Hashing passwords isn’t even the best practice at this point”? Key derivation functions are certainly the recommended approach these days. If they are hashes, then your earlier post is wrong, and if they aren’t hashes, then your next post was wrong.
The rest of that sentence is important. Hashing passwords is the minimum practice, not best practice. You should always be at least hashing passwords. Best practice would be salting and peppering them as well as picking a strong hashing function with as high a number of iterations as you can support. You would then pair that with 2FA (not SMS based), and a minimum password length of 16 with no maximum length.
Lots of older databases had fixed length fields, and you had to pad it if it was smaller.
VARCHARis a relatively new thing. So it’s not just saving space, but that old databases tended to force the issue.Nobody has an excuse today. Even Cobol has variable length strings.
Microsoft used to do that. I made a password in the late 90’s for a we service and I found out that it truncated my password when they made it after it warned my my password was too long when I tried to log in. It truncated at 16 characters.
The weirdest one I found was a site that would only check to see if what you entered started with the correct password. So if your password was hunter2 and you tried hunter246, it would let you in.
Which means not only were they storing the password, but they had to go out of their way to use the wrong kind of string comparison.
USAA does this. I renentl learned that, when I updated my password a few years back to my personal standard number of characters, everything was good until someone mentioned this fuck-up in a thread. USAA only checks the first… 16? characters. I assume it just discards anything beyond that. Other users say that it warns and doesn’t let you enter more than that during password creation, but it/my pw mgr sure didn’t care, as I have a password several fold that limit. I took out a couple characters from my ‘set’ password, and it still logged in just fine. 16, just fine. 15, error.
Fucking wild.
I used to work there. I reported this bug every quarter until a VP told me to stop…
The LM password hash (predecessor to NTLM) was calculated in two blocks of 7 characters from that truncated 14 characters. Which meant the rainbow table for that is much smaller than necessary and if your password is not 14 characters, then technically part of the hash is much easier to brute force, because the other missing characters are just padded with null.
What kind of barbarian puts a space in their password?
Very common for pass phrases, and not dissuaded. Pass phrases are good for people to remember without using poor storage practices (post it notes, txt file, etc) and are strong enough to keep secure against brute force attacks or just guessing based off knowledge of the user.
On one hand, that’s true. On the other hand, a person should only need exactly one passphrase, which is the one used to unlock their password manager. Every other password should be randomly-generated and would only contain space characters by chance.
That’s great in theory, but you’ll have passwords for logging into OSes too which password managers do not help with and you better have it memorized or you’re going to have a bad time.
Deleted
Deleted
That’s the “zero width space,” Alt + 200B for Windows users. Another favorite of mine is the nonbreaking space, Alt + 0160, which a staggering majority of web sites and other systems fail to account for.
gosh who would want an uncommon character that obviously most average people aren’t thinking about in their passwords, that sounds like it might even be somewhat secure.
hunter 2unhackable
My passphrase includes several spaces. It’s another character to assist in entropy.
I’m with you, despite seeing lemmings downvote the heck out of your comment 😢
The reason, and specifically for whitespace at the beginning or end of a password, is that a lot of users copy-paste their passwords into the form, and for various reasons, whitespace can get pasted in, causing an invalid match. No bueno.
Source: I’m a web developer who has seen this enough times that we had to implement a whitespace-trim validation for both setting & entering passwords.
Trimming whitespace from the start and end of a password is fine but you absolutely should not remove whitespace from the middle of a password.
NIST are bureaucrats sure, but bureaucrats with lots and lots of practical experience.
It needed to be said. Because some password system architects have been just that stupid.
Edit: Fear of other’s stupidity is the mind killer. I will face my fear. My fear will wash over me, and when it has passed, only I will remain. Or I’ll be dead in a car accident caused by an AI driver.
I’ve seen sites truncate when setting, but not on checking. So you set a password on a site with no stated limit, go to use said password, and get locked out. It’s infuriating
Sounds like my bank.
Banks usually have the absolute worst password policies. It’s typically because their backend is some crusty mainframe from the 80s that limits inputs to something absurdly insecure by today’s standards and they’ve kicked the upgrade can down the road for so long now that it’s a staggeringly monumental task to rewrite it all. Thankfully most of them have upgraded at this point, but every now and then you still find one that’s got ridiculous limits like a maximum password length of 8 and only alphanumeric characters (with no 2FA obviously).
Years back, I had that happen on PayPal of all websites. Their account creation and reset pages silently and automatically truncated my password to 16 chars or something before hashing, but the actual login page didn’t, so the password didn’t work at all unless I backspaced it to the character limit. I forgot how I even found that out but it was a very frustrating few hours.
Another ridiculous policy I’ve seen (many years ago) is logging in too fast. I used to get locked out of my banks website all the time and I used autotype with KeePass so I was baffled when it wouldn’t get accepted. Eventually I had a thought to slow down the typing mechanism and suddenly I didn’t get locked out anymore.
Only issue I see is that the 8 chars required is very short and easy to brute force. You would hope that people would go for the recommended instead, but doubt it.
I think if you do allow 8 character passwords the only stipulation is that you check it against known compromised password lists. Again, pretty reasonable.
That stipulation goes rather close to #5, even not being a composition rule.EDIT: see below.I think that a better approach is to follow the recommended min length (15 chars), unless there are good reasons to lower it and you’re reasonably sure that your delay between failed password attempts works flawlessly.
EDIT: as I was re-reading the original, I found the relevant excerpt:
So they are requiring CSPs to do what you said, and check it against a list of compromised passwords. However they aren’t associating it with password length; on that, the Appendix 2 basically says that min length depends on the threat model being addressed; as in, if it’s just some muppet trying passwords online versus trying it offline.
Hmm. I wonder about this one. Different ways to encode the same character. Different ways to calculate the length. No obvious max byte size.
Who cares? It’s going to be hashed anyway. If the same user can generate the same input, it will result in the same hash. If another user can’t generate the same input, well, that’s really rather the point. And I can’t think of a single backend, language, or framework that doesn’t treat a single Unicode character as one character. Byte length of the character is irrelevant as long as you’re not doing something ridiculous like intentionally parsing your input in binary and blithely assuming that every character must be 8 bits in length.
It matters for bcrypt/scrypt. They have a 72 byte limit. Not characters, bytes.
That said, I also think it doesn’t matter much. Reasonable length passphrases that could be covered by the old Latin-1 charset can easily fit in that. If you’re talking about KJC languages, then each character is actually a whole word, and you’re packing a lot of entropy into one character. 72 bytes is already beyond what’s needed for security; it’s diminishing returns at that point.
Yes, if. I don’t know if you can guarantee that. It’s all fun and games as long as you’re doing English. In other languages, you get characters that can be encoded in more than 1 way. User at home has a localized keyboard with a dedicated key for such a character. User travels across the border and has a different language keyboard and uses a different way to create the character. Euro problems.
en.wikipedia.org/wiki/Unicode_equivalence
There is always some son-of-a-bitch who doesn’t get the word.
re #7, I hope they are also saying no ‘secret questions’ to reset the password?
I think so, based on the original: “Verifiers and CSPs [credential service providers] SHALL NOT permit the subscriber to store a hint that is accessible to an unauthenticated claimant.” With “shall not” being used for hard prohibitions.
Yeah, I think 7 and 8 both cover that. I recently signed up for an account where all of the “security questions” provided asked about things that could be either looked up or reasonably guessed based on looked up information.
We live in a tech world designed for the technically illiterate.
Sarah Palin had her Yahoo mail account hacked because of those “security” questions. In 2008. We should be well past the time where they are a thing.
Q: What do you often see when you look out your back window?
A: Vladimir Putin riding a horse shirtless.
Hey maybe the GOP got connected with Putin because he was often at Palin’s backyard BBQs when he would ride over to say hi when he saw the gathering.
Though I also just noticed there’s only two letters different between Putin and Palin… Maybe it was just Putin in a wig the whole time.
I usually invent answers to those and store those answers in a password manager. Essentially turns them into backup passwords that can be spoken over the phone if necessary.
Where was I born? “Stallheim, EUSA, Mars”
Name of first pet? “Groovy Tuesday”
It’s fun, usually.
I tried that without a password manager for a little while. But then my answers were too abstract to remember, so now I also use a password manager for that.
What is the first name of your first best friend?
Oh old eoY&Z9m4LNRDY!Gzdd%q98LYiBi8Nq and I go way back! I met eoY&Z9m4LNRDY!Gzdd%q98LYiBi8Nq in Pre-K and we’ve been inseparable ever since.
It is quite annoying if they’re a service that makes you read aloud your security questions to phone reps to prove your identity. One of my retirement accounts requires that and I have to sigh and read out the full string. I’ve changed it since to an all lowercase, 20 digit string as a compromise.
20 character all lowercase is very secure as long as its random words / letters that would make it unguessable by knowing you.
Edit: you could also prefix it if you think you’d have to read it
“This question is stupid fuck nuts house gravel neptune cow.”
This is a big one. Especially in corporate environments where most of the users are, shall we say, not tech savvy. Forcing people to comply with byzantine incomprehensible password composition rules plus incessantly insisting that they change their password every 7/14/30 days to a new inscrutable string that looks like somebody sneezed in punctuation marks accomplishes nothing other than enticing everyone to just write their password down on a Post-It and stick it to their monitor or under their keyboard.
Remember: Users do not care about passwords. From the perspective of anyone who isn’t a programmer or a security expert, passwords are just yet another exasperating roadblock some nerd keeps putting in front of them that is preventing them from doing whatever it is they were actually trying to do.
Everyone I’ve spoken to who has a password change rule just changes one character from their previous password. It does NOTHING.
That works great until some dickhole implements the old, “New password cannot contain any sequence from your previous (5) passwords.”
This also of course necessitates storing (multiple successive!) passwords in plain text or with a reversible cipher, which is another stupid move. You’d think we’d have gotten all of this out of our collective system as a society by now, and yet I still see it all the time.
All of these schemes are just security theater, and actively make the system in question less secure while accomplishing nothing other than berating and frustrating its users.
HA, I hope you’re joking. Surely nobody’s actually done that, right? …Riiiight?
This also leads to stupid rules like you can’t change your password more than once a day, to prevent someone from changing their password 5 times and then changing it back to what it was before.
“I just increment the number at the end” is a phrase I’ve heard so many times
NIST knows what they’re doing. It’s getting organizations to adapt that’s hard. NIST has recommended against expiring passwords for like a decade already, for example, yet pretty much every IT dept still has passwords expiring at least once a year.
I think it’s pretty idiotic to
They might mean well, but the reason we require a special character and number is to ensure the amount of possible characters are increased.
If a website doesn’t enforce it, people are just going to do a password like password
password is a totally valid password under this rule. Any 8 letter word is valid. hopsital for example.
These passwords can be cracked in
secondsunder 10 minutes, and have their hashes checked for in leaks in no time if the salt is also exposed in the hack.Edit: Below
Numbers from a calculator with 8 characters using sha2 (ignoring that crackers will try obvious fill ins like 0 for o and words before random characters, this is just for example)
hospital 5m 23s
Hospital 10m 47s
Hospita! 39m 12s
Moving beyond 8
Hospita!r - 19h 49m
Hospita!ro 3w 4d
Hospita!roo 2y 1m
Hospita!room 66 years
The suggestion of multiple random words makes not needing the characters but you have to enforce a longer limit then, not 8.
At least with 11 characters with upper case and special characters if it was all random you get about 2 years after a breach to do something instead of mere weeks. If it was 11 characters all lower case nothing special you’d only get 2 months and we are rarely notified that fast.
The problem with this sort of requirement is that most people will solve it the laziest way. In this case, “ah, I can’t use «hospital»? Mkay, «Hospital1» it is! Yay it’s accepted!”. And then there’s zero additional entropy - because the first char still has 26 states, and the additional char has one state.
Someone could of course “solve” this by inserting even further rules, like “you must have at least one number and one capital letter inside the password”, but then you get users annotating the password in a .txt file because it’s too hard to remember where they capitalised it or did their 1337.
Instead just skip all those silly rules. If offline attacks are such a concern, increase the min pass length. Using both lengths provided by the guidelines:
But they mess that up with their 8 char rule
I’d they’d just said shall require 15 but not require special chars then that’s okay, but they didn’t.
Then you end up with the typical shitty manager who sees this, and says they recommend 8 and no special chars, and that’s what it becomes.
I don’t think that the entity should be blamed for the shitty manager. Specially given that the document has a full section (appendix A.2) talking about pass length.
The entity knows people will follow what they say for minimums. There’s already someone in the comment section saying they’re now fighting what these lax rules allow.
Edit: stupid product managers will jump at anything that makes it easier for their users and dropping it to 8, no special characters, and no resets is the new thing now.
What you’re proposing is effectively the same as "they should publish inaccurate guidelines that do not actually represent their informed views on the matter, misleading everybody, to pretend that they can prevent the stupid from being stupid." It defeats the very reason why guidelines exist - to guide you towards the optimal approach in a given situation.
And sometimes the optimal approach is not a bigger min length. Convenience and possible vectors of attack play a huge role; if
min 8 chars is probably better. Even if that shitty manager, too dumb to understand that he shouldn’t contradict the “SHOULD [NOT]” points without a good reason to do so, screws it up. (He’s likely also violating the “SHALL [NOT]” points, since he used the printed copy of the guidelines as toilet paper.)
It’s crazy that they didn’t include all the “should” items in that list. If you read the entire section, there’s a critical element that’s missing in the list, which is that new passwords should be checked against blocklists. Otherwise, if you combine 1, 5, and 6, you end up with people using “password” as their password, and keeping that forever. Really, really poor organization on their part. I’m already fighting this at work.
i had to login for some functions at work. i believe the minimums were 8 characters, 1 caapitol, 1 number. and we all hated it, because the passwords had to be changed every 90 days, and you couldn’t reuse passwords. eventually you are going to run out of things you can reasonably use that you could remember and then would be forced to use some sort of password manager. but OOPSIE you couldn’t install any software on the office computer so you would have to resort to writing them down somewhere. it was a mess.
fortunately corporate decided to just change the entire system adopting most of these rules, min 15 characters, no special character, no hints, no forced changing passwords unless you think you have been compromised or just want to change it. we do have to use 2fa to access some things if you aren’t sitting at the office computer but other than that people are much happier about passwords now.
Half the users passwords is going to be {Company}@{YEAR}
Don’t forget classics like Fuck_this_shit1! Fuck_this_shit2!
Oh umm. I would never make my password this…
Deleted
I feel like it’s not a big impact on security if I use 2fa anyway. (Base password)(month)(year) is fine for me 😅
I would always just create 1 password and append a number and it’s special char, cycling from 1 to 0; like
1!,2@,3#. Never stayed at a place long enough to go higher than 7 or 8.I never gave a fuck about doing this because it’s the companies fault for applying stupid policies. Whenever I’ve been allowed a password manager, they got real security instead of malicious compliance.
Ah, the downstream effects of compliance teams.
“Hurry we gotta check off all the boxes!!! What do these measures actually address? Don’t know, don’t care! Comply!”
Stockholm1 (capitol)
90 days later:
Stockholm2
You heard it: stop imposing composition rules!
Cracking an 8-char on an ordinary desktop or laptop PC can still take quite a while depending on the details. Unfortunately, the existence of specialized crypto-coin-mining rigs designed to spit out hashes at high speed, plus the ability to farm things out into the cloud, means that the threat we’re facing is no longer the lone hacker cracking things on his own PC.
Newer password hashing algorithms have ways of combatting this. For example, argon2 will use a large amount of memory and CPU and can be tuned for execution time. So theoretically you could configure it to take 0.5 seconds per hash calculation and use 1 GB or more of ram. That’s going to be extremely difficult to bruteforce 8 characters.
The trade-off is it will take a second or two to login each time, but if you’ve got some secondary pin system in place for frequent reauthentication, it can be a pretty good setup.
Another disadvantage is the algorithm effectively gets less secure the less powerful your local device is. Calculating that same 0.5s hash on a beefy server vs your phone could make it take way longer or even impossible without enough ram.
Unfortunately, it’s rare that we can control what hashing algorithm is being used to secure the passwords we enter. I merely pray that any account that also holds my credit card data or other important information isn’t using MD5. Some companies still don’t take cybersecurity seriously.
Storing credit card data has its own set of strict security rules that need to be followed. It’s also the credit card company’s problem, not yours, as long as you dispute any fraudulent charges early enough.
I’m coming at this from the perspective of a developer. A user can always use a longer password (and you should), but it’s technically possible to make an 8 character password secure, thus the NIST recommend minimum.
About damn time. I log into my company laptop with a smart card and PIN or a PIN/authenticator code, computer autoconnects to the VPN, and I’m good to go. If there’s no internet available, the smart card will still get me into my computer. If I’m on my personal computer, I log in with the PIN/authenticator. This morning I tried really hard to find someplace where I had the option of entering a password and there is none, yet I have to change my password every 6 months. At least my IT department lets me use KeePass.
I’ll log into my home desktop and I’ll get a message telling me that “it’s time to reset your password!”
First of all, how dare you, on my computer? In my home?
Secondly, I don’t even have a password on this thing
Eh, I think they should nag users to change their password proportional to how “strong” their password is. If you’re barely meeting the minimum: reset every few months. If you’re using a proper passphrase dozens of characters long: only reset if there’s evidence of compromise.
How about making it illegal to block copying and pasting on website forms. I’m literally more likely to make a mistake by typing a routing number than copying and pasting it. The penalty for should be death by firing into the sun to anyone caught implementing any such stupidity.
I circumvent that by right-clicking, then choosing “Inspect element”, then switching to the tab “Console”, then typing $0.value = “TheValueIWantToPaste”. If right-clicking is also disabled, I use either F12 or Tools menu > DevTools.
that’s so easy! /s
easier than typing out a long string
And here I wrote an AutoHotKey script to type out my clipboard a character at a time so I can paste stuff into this remote desktop software I’m using that doesn’t support paste…
It’s kinda necessary when the server’s unlock password is 256 characters long and completely random.
if it’s citrix you used to be able to modify the local connection config file to allow access to the clipboard regardless of what the server allowed.
been a few years since I needed to do it, but it was possible at one time.
Or just delete the “readonly” bit. I did that on Treasury Direct for years until they finally removed that nonsense.
Sometimes it’s not “readonly”, but a Javascript thing that “event.preventDefault()” and “return false” during the “onpaste” event. As the event is generally set using elm.addEventListener instead of setting elm.onpaste, it’s not possible to remove the listener, as it’d need the reference for the handler function that was set to handle the mentioned JS event. So simply setting the value directly using elm.value bypasses the onpaste event.
That’s fair, not sure why they’d go through that much effort when DOM attributes exist.
That sounds fun on mobile
Frankly I’m mostly annoyed that my browser allows web sites to block cut and paste, ever. I am capable of making my own decisions over whether I want to cut and paste.
There are plugins that will disallow this. I think the one I use is “don’t fuck with paste”
Never thought to look for an extension for that. Thanks for mentioning it.
You can also just run it when you need it rather than having to add an extension. Just add a bookmarklet with the code here and just click it when you encounter a problematic website.
It’ll reduce your attack surface while still getting the job done.
github.com/jswanner/DontF-WithPaste?tab=readme-ov…
Even better, thanks!
Ooh, ooh. And for implementing any Javascript or jQuery or whatever that pops up some kind of smarmy message when you right click: Believe it or not, straight to jail.
Plus, that kind of thing is not going to prevent anyone from scraping images from anywhere if they have the capability to lift a finger to press F12.
Exactly.
My host decided to update their TOS to force me to accept binding arbitration, so I Inspect Elemented that right off the page and sent a message to support to end my service effective immediately (had been a paying customer for years). You’re not going to bully me on my own browser…
It won’t block it yes but it will diminish the amount of people doing it which is the point
Some do detect open developer tools and nuke the whole page, though.
Browsers shouldn’t allow half of the stuff that they allow. You have to do the same thing not just with copy and paste, but also searching on the page with
ctrl + f. Like I don’t care that websites won’t to create their own experience. Don’t mess with browser behavior.You really want to memorise different shortcuts for search? What if you’re on a web app like discord? Ctrl+f isn’t gonna be as useful as a built in search solution that has access to data that isn’t visible until searched for. I get the issues on disabling the features but if they’re replacing browser behaviour with something that suits the site better I think that’s alright as long as it’s not s downgrade.
All too often it is a downgrade though. A lot of those webapps have terrible search and I only want to search for what is on the current page anyways. For example reddit search has been notoriously bad for a long time. Half the forums online seem to be using the exact same open source software with the exact same terrible search. When all too often I just want to find what is on the current page anyways.
Don’t forget you save lots of fuel by firing out of the solar system instead
It takes way less Delta V to push them into solar escape velocity.
Anger is no excuse to be inefficient with propellant after all
Idk, it might delay the sun imploding a smidge. Or maybe it would accelerate it. Eh, they know what they’re doing…
Think of the environment!
Less Delta-V to eject them from the solar system.
One thing they should change is the word “password.” This implies that it’s a short string. Changing it to “passphrase” will help people feel comfortable choosing credentials like “correct horse battery staple.”
I recently set up a password with a 16 character max, alphanumeric only, no spaces. The service is in no way a security threat but still.
A couple years ago I ran into one with a 12 character limit…
I never understood password limits, other than something sufficiently large like 256 to prevent DOS. It’s not like the password is actually being stored anywhere… right? RIGHT??
The app my work uses to show 401k, pay, request leave, etc details, uses a ridiculous webapp that’s very slow, and on top of this, they nag you literally every 4 months to update your password. I used to be a good boy and memorize a new password each time. Now I just add a new letter into BitWarden and it’s my new password. Apparently this is more secure??
I just add 1 to the number at the end of my password every time they force a change.
I’m on 18 right now.
My favorite are some of the work systems that I need to access, but only infrequently, yet still have ridiculous password expiration rules. Nearly every time I log in, before I can access the system I have to change my password because of course it’s expired again. So I change the password, write it down because I’ll never remember it months from now when I need to use that password exactly once to login and change my password yet again.
Interesting that unicode support is suggested. Emoji passwords could be fun.
Multiple languages.
Yeah, multiple languages or even putting an ê or something in an English password to mix things up. It makes perfect sense to allow.
It’s a good thing they require each codepoint to be treated as one character for the length limit, since “🤔🤣” is 8 bytes on its own, but the unicode prefix is trivial to guess.
Characters are characters. The system I just wrote will accept anything, because the first thing I do with it is hash it. If you want to make your password:
░▒▓█ ʥ۞ݔݯݲݸݴݺ '; drop table
users; 🤣💩ʩ █▓▒░Then go for it. More power to you for typing that out or, more likely, letting your password manager remember it. Make your password as entropic as you can manage, I don’t care how you arrive there.
Haha, and I smiled when I looking for the single quote in your password and sure it is there👍👍
Yup. All I care is that your password isn’t the entire works of Shakespeare or something like that. A couple hundred characters/bytes? You do you.
What really bothers me is when a website says something like: must have a special character, except these ones (proceeds to list everything except @ and !). And then the next one has the same rule, but different exceptions.
Passwords should be treated as a black box, just read it as bytes and throw it into the hash algorithm. You want to somehow enter a nyan cat? Be my guest, no guarantee the input box will accept it though.
also: “password is too long, max password length is 12 digits”
Why… like, sure, cap it at 256 or something reasonable. but ive run into as low as 9 digits.
I had a simulator for school truncate after like 13 characters. And nowhere on their page did it specify a character limit. Would still accept an input of like 64 characters though. Got locked out of that account many times.
I’ve run into similar: on the account creation page there was no character limit on the input box nor stated in the password requirements, but on the login page the password input box was limited to 14 characters. So you could successfully create an account with a long password, you just couldn’t log in because it wouldn’t let you enter the whole password.
One of the four major banks in Australia used to (or maybe still does?) limit passwords to 6 characters. No more, no less. Exactly 6. They’re case insensitive, too.
One of the other banks used to silently truncate passwords (to 12 characters if I remember correctly). They removed the truncation one day, and there were so many issues because people who had passwords longer than 12 characters couldn’t log in unless they knew to only enter the first 12 characters of it. It was a mess. Their phone support had a recorded message saying to only enter the first 12 characters if you have trouble logging in.
my password is just 20 gigabytes of poop emojis.
Emoji passwords made me think of the Lotus Notes password prompt with their little images that changed as I typed (which never really made sense to me).
Yes, I’m old…
Meanwhile, my company has systems insisting on expiring ssh keys after 90 days…
My company blocked ssh keys in favour of password + 2FA. Honestly I don’t mind the 2FA since we use yubikeys, but wouldn’t ssh key + 2FA be better?
.
We use keys + Yubikey 2FA (the long alphanumeric strings when you touch the Yubikey) at work, alhough they want to move all 2FA to Yubikey FIDO2/WebAuthn in the future since regular numeric/text 2FA codes are vulnerable to phishing. All our internal webapps already require FIDO2, as does our email (Microsoft 365).
Just store your keys on the yubikey. Problem solved.
Or use a smart card profile and go that route.
All well and good when ssh activity is anchored in a human doing interactive stuff, but not as helpful when there’s a lot of headless automation that has to get from point a to point b.
Yep. All the headless automation broke…
I’m surprised they’d expire the SSH keys rather than just requiring the password for the key to be rotated. I guess it’s not too bad if the key itself is automatically rotated.
It would be more secure to have SSH keys that are stored on Yubikeys, though. Get the Yubikeys that check fingerprints (Yubikey Bio) if you’re extra paranoid.
Problem they had was that ssh doesn’t really have any way to enforce details of how the client key manifests and behaves. They could ship out the authentication devices after the security team trusted the public key, but that was more than they would have been willing to deal with.
Rotating the passphrase in the key wouldn’t do any good anyway. If an attacker got a hold of your encrypted key to start guessing the passphrase, that instance of the key will never know that another copy has a passphrase change.
Fools! You have to expire the whole system!
Reinstall everything every 90 days. It’s the only way.
You are going to give them ideas…
Ironically, reinstall the whole system, make sure to add some CrowdStrike, SolarWinds, and Ivanti for security and management though…
All this 2FA, SSH, token / key stuff is garbage. Rectal vascular mapping is the only legitimate security option.
It took me a moment to notice those weren’t specifically security terms…
I have one in my house! 🏡 Just reverse into it and Viola! The door opens! Works for the ref too! Hands free baby!
Now this is security I can get behind! Err, in front of?