Why Do So Many Sites Have Bad Password Policies? (gatech.edu) 242
"Three out of four of the world's most popular websites are failing to meet minimum requirement standards" for password security, reports Georgia Tech's College of Computing. Which means three out of four of the world's most popular web sites are "allowing tens of millions of users to create weak passwords."
Using a first-of-its-kind automated tool that can assess a website's password creation policies, researchers also discovered that 12% of websites completely lacked password length requirements. Assistant Professor Frank Li and Ph.D. student Suood Al Roomi in Georgia Tech's School of Cybersecurity and Privacy created the automated assessment tool to explore all sites in the Google Chrome User Experience Report (CrUX), a database of one million websites and pages.
Li and Al Roomi's method of inferring password policies succeeded on over 20,000 sites in the database and showed that many sites:
- Permit very short passwords
- Do not block common passwords
- Use outdated requirements like complex characters
The researchers also discovered that only a few sites fully follow standard guidelines, while most stick to outdated guidelines from 2004... More than half of the websites in the study accepted passwords with six characters or less, with 75% failing to require the recommended eight-character minimum. Around 12% of had no length requirements, and 30% did not support spaces or special characters. Only 28% of the websites studied enforced a password block list, which means thousands of sites are vulnerable to cyber criminals who might try to use common passwords to break into a user's account, also known as a password spraying attack.
Georgia Tech describes the new research as "the largest study of its kind." ("The project was 135 times larger than previous works that relied on manual methods and smaller sample sizes.")
"As a security community, we've identified and developed various solutions and best practices for improving internet and web security," said assistant professor Li. "It's crucial that we investigate whether those solutions or guidelines are actually adopted in practice to understand whether security is improving in reality."
The Slashdot community has already noticed the problem, judging by a recent post from eggegick. "Every site I visit has its own idea of the minimum and maximum number of characters, the number of digits, the number of upper/lowercase characters, the number of punctuation characters allowed and even what punctuation characters are allowed and which are not." The limit of password size really torques me, as that suggests they are storing the password (they need to limit storage size), rather than its hash value (fixed size), which is a real security blunder. Also, the stupid dots drive me bonkers, especially when there is no "unhide" button. For crying out loud, nobody is looking over my shoulder! Make the "unhide" default.
"The 'dots' are bad security," agrees long-time Slashdot reader Spazmania. "If you're going to obscure the password you should also obscure the length of the password." But in their comment on the original submission, they also point out that there is a standard for passwords, from the National Institute of Standards and Technology: Briefly:
* Minimum 8 characters
* Must allow at least 64 characters.
* No constraints on what printing characters can be used (including high unicode)
* No requirements on what characters must be used or in what order or proportion
This is expected to be paired with a system which does some additional and critical things:
* Maintain a database of known compromised passwords (e.g. from public password dictionaries) and reject any passwords found in the database.
* Pair the password with a second authentication factor such as a security token or cell phone sms. Require both to log in.
* Limit the number of passwords which can be attempted per time period. At one attempt per second, even the smallest password dictionaries would take hundreds of years to try...
Someone attempting to brute force a password from outside on a rate-limited system is limited to the rate, regardless of how computing power advances. If the system enforces a rate limit of 1 try per second, the time to crack an 8-character password containing only lower case letters is still more than 6,000 years.
Using a first-of-its-kind automated tool that can assess a website's password creation policies, researchers also discovered that 12% of websites completely lacked password length requirements. Assistant Professor Frank Li and Ph.D. student Suood Al Roomi in Georgia Tech's School of Cybersecurity and Privacy created the automated assessment tool to explore all sites in the Google Chrome User Experience Report (CrUX), a database of one million websites and pages.
Li and Al Roomi's method of inferring password policies succeeded on over 20,000 sites in the database and showed that many sites:
- Permit very short passwords
- Do not block common passwords
- Use outdated requirements like complex characters
The researchers also discovered that only a few sites fully follow standard guidelines, while most stick to outdated guidelines from 2004... More than half of the websites in the study accepted passwords with six characters or less, with 75% failing to require the recommended eight-character minimum. Around 12% of had no length requirements, and 30% did not support spaces or special characters. Only 28% of the websites studied enforced a password block list, which means thousands of sites are vulnerable to cyber criminals who might try to use common passwords to break into a user's account, also known as a password spraying attack.
Georgia Tech describes the new research as "the largest study of its kind." ("The project was 135 times larger than previous works that relied on manual methods and smaller sample sizes.")
"As a security community, we've identified and developed various solutions and best practices for improving internet and web security," said assistant professor Li. "It's crucial that we investigate whether those solutions or guidelines are actually adopted in practice to understand whether security is improving in reality."
The Slashdot community has already noticed the problem, judging by a recent post from eggegick. "Every site I visit has its own idea of the minimum and maximum number of characters, the number of digits, the number of upper/lowercase characters, the number of punctuation characters allowed and even what punctuation characters are allowed and which are not." The limit of password size really torques me, as that suggests they are storing the password (they need to limit storage size), rather than its hash value (fixed size), which is a real security blunder. Also, the stupid dots drive me bonkers, especially when there is no "unhide" button. For crying out loud, nobody is looking over my shoulder! Make the "unhide" default.
"The 'dots' are bad security," agrees long-time Slashdot reader Spazmania. "If you're going to obscure the password you should also obscure the length of the password." But in their comment on the original submission, they also point out that there is a standard for passwords, from the National Institute of Standards and Technology: Briefly:
* Minimum 8 characters
* Must allow at least 64 characters.
* No constraints on what printing characters can be used (including high unicode)
* No requirements on what characters must be used or in what order or proportion
This is expected to be paired with a system which does some additional and critical things:
* Maintain a database of known compromised passwords (e.g. from public password dictionaries) and reject any passwords found in the database.
* Pair the password with a second authentication factor such as a security token or cell phone sms. Require both to log in.
* Limit the number of passwords which can be attempted per time period. At one attempt per second, even the smallest password dictionaries would take hundreds of years to try...
Someone attempting to brute force a password from outside on a rate-limited system is limited to the rate, regardless of how computing power advances. If the system enforces a rate limit of 1 try per second, the time to crack an 8-character password containing only lower case letters is still more than 6,000 years.
We already know that. (Score:5, Insightful)
The umpteenth paper saying how bad everything is isn't going to change anything.
Why isn't there some reference implementation of some password generation/validation thing that everyone can point to that is kept up-to-date with current best-practices? Why are sites still allowed to have their own homegrown password thing, and not forced to use some industry standard?
Re:We already know that. (Score:4, Funny)
Re:We already know that. (Score:4, Insightful)
forcing pw changes every 60 days with a 15 pw history that cant repeat.
I said:
kept up-to-date with current best-practices
As I understand it, password changes is not current best-practice. Thank you for highlighting my point. Best practices are too hard to keep up with manually. It's better if you have reference implementations that removes these out-of-date practices as fast as possible, and have developers use these, instead of having to trust each developer to be properly and timely educated, on top of implementing the new rules correctly.
You should learn to read and carefully consider what has been said, before trying to nitpick with a point that is already accounted for.
As for 2FA, that's a shit solution. You shouldn't have to have a phone just to use websites. We need a better way that's not dependent on a phone that could get lost, or you'd have to change and then you'd have to remember to update every possible website with your phone details.
Re: (Score:3)
SMS 2FA is stupid. 2FA that uses either TOTP through software (such as Google Authenticator or Authy) or a hardware key is great. Especially since both solutions (if implemented properly) don't require a phone or a phone number.
Re: (Score:3)
Why isn't there some reference implementation ...
I say money. Which costs more, not messing with current practices or rolling out best practices?
In another example, users inside heavy tech and residents alike still click on malicious links. The onus is on employees and consumers to comply with best practices. How hard would it be to have AI trace a link to a destination, evaluate the endpoint for harm, and act accordingly? The answer to that question is another question: How much would it cost?
Until Big Tech loses money over sloppy work, there's no need t
Re: (Score:3)
You can also rank sites into those where no password is necessary, but they require one because they're dicks and want to track you. Who cares about them. Use "abc" as your password, if someone steals your account then you have actually gained something. Then the forums - who cares if someone steals it? Use "abcde".
THEN worry about stuff where it matters - your bank, shopping sites (though cut those down to a minimum and use those that don't require accounts if you can), or any site that has other info ab
Re:We already know that. (Score:4, Insightful)
Password policy is DEFINITELY the government's business, insofar as being part of the data protection laws.
Re: (Score:3)
Companies should be liable for data losses, and that should give them ample incentive to have reasonable policies appropriate for what is being protected.
Re: (Score:2)
Companies should be liable for data losses, and that should give them ample incentive
Except we know that it doesn't.
Most data breaches aren't because someone deliberately decided to have weak security. It is far more likely to be just plain old-fashioned incompetence by people who didn't even know they were doing it wrong.
People used to roll their own encryption. Widespread libraries and frameworks that incorporate standard encryption algorithms have mostly ended that.
We can do the same with passwords.
Re: (Score:3)
The passwords should never leave the browser (Score:3, Informative)
The old Digest Authentication almost got it correct. But there are better PAKE algorithms, in particular Secure Remote Password is excellent.
That would enable one to use the same weak password everywhere and be secure.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
I agree with this. Entities that are breached are guilty, IMHO, of negligence. As we know, not all breaches, but enough, exploit vulnerabilities that have been previously patched. It's cheaper to ignore those updates than to implement measures whether they be qualified and empowered IT staff or using AI.
The gatekeepers should be held responsible for sleeping on watch.
Re: (Score:2)
Re: We already know that. (Score:3)
Re: (Score:3)
Governments may be part of the problem here. Companies generally don't want to become security experts, or justify their security decisions. They just go to some authority, like NIST or another government agency, and follow their guidelines.
If they get hacked, their defence is that they followed the best government advice. Appeals to authority may be a logical fallacy, but they make good legal defences.
Of course, the government advice tends to be out of date, and gets updated very slowly. NIST, for example,
Re:We already know that. (Score:4, Insightful)
The site's insurance carrier has a legitimate say.
Re: (Score:2)
GDPR entered the chat.
Re: (Score:2)
Because they handle large sums of money that are (up to some extent) insured by the government?
Re: (Score:2)
Re: (Score:2)
Please tell me that's hyperbole and that dimwit at least didn't cross that line.
Re: (Score:2)
Please tell me that's hyperbole and that dimwit at least didn't cross that line.
DeSantis said that some slaves benefited by learning skills such as blacksmithing.
He didn't say all slaves benefited or that slavery was a good thing overall.
His campaign is gasping for oxygen. He is falling in the polls. Haley is ahead of him in the early primary states, and Trump is way ahead of both. So it makes sense for him to say provocative things to keep the press from ignoring him. The people who are offended weren't gonna vote for him anyway.
Password lockout (Score:3)
Someone attempting to brute force a password from outside on a rate-limited system is limited to the rate, regardless of how computing power advances. If the system enforces a rate limit of 1 try per second, the time to crack an 8-character password containing only lower case letters is still more than 6,000 years.
What should happen is if a password is entered incorrectly five times the person (or more likely a bot) has to wait 1 minute before trying again. If another five times are incorrect the timer goes to five minutes. If another five misses, ten minutes, and so on up to one hour, and each five misses thereafter is an hour (the max limit).
While the rate limit is 1 try per second, this method would make it less comfotable for bots and their keepers since it would take even longer to brute force. And yes, there will be users caught up in this, but they need to get their act together.
Re:Password lockout (Score:4, Insightful)
Won't work: if the limit is not IP-specific, you can trivially DOS another user you don't like. If it is, bots have plenty of IPs anyway (and, while a given IP can do only a small sliver of work for that particular site, it can do many other tasks the rest of the time).
Re: (Score:2)
If the lock is IP specific then users behind CGNAT will get locked out.
If the lock is by user, then the bots can simply try a large number of accounts with a small number of the most common passwords.
Re:Password lockout (Score:5, Insightful)
Do NOT do that! It allows an attacker to make accounts effectively inaccessible and will just give your IT support people a lot of pain. Instead just put in a 30 or 60 second delay after 3 failed tries, but do NOT increase that delay.
Re: (Score:2)
What do you mean "get their act together"...
If i've set a strong password on a site then that's the most i can do, and yet anyone who knows my username is able to keep my account locked out and unusable indefinitely. The user in this case can't do anything about it.
Re:Password lockout (Score:4, Insightful)
Not really, one password attempt per second is a sensible rule. It does not interfere with anything a normal human would do but effectively keeps a script from hammering a password.
5 attempts and waiting 5 minutes if you fail pisses off a human while not really impeding a script any more than the one password every other second rule.
Ditch the password (Score:3)
Re: (Score:2)
The password is the #1 problem in cyber security.
Wrong. Humans are the #1 problem in cyber security.
I was once asked a question during an interview what I thought was the biggest threat to an organization. I replied it was it was the people of the organization. By the look on the interviewers faces that wasn't the answer they were looking for. However, it was the right answer.
Re: Ditch the password (Score:2)
Re: (Score:2)
And replace them by what exactly?
We have to remove the human factor. As long as humans are involved, security is not going to improve. Humans will hand over any and every kind of access to a scammer promising them a dancing pony.
Re: (Score:2)
Re: (Score:2)
Humans are the #1 problem in cyber security.
Indeed. If the policies are bad it's because one or more of (a) companies are cheap, (b) companies don't care, etc -- I'll throw in (c) programmers are lazy / don't care / are inexperienced, but that assumes it's actually up to them... More to the point, as long as the implemented policy *allows* users to enter strong passwords, then the bad passwords are on the users. [Said as a developer/sysadmin use to using strong(er) passwords.]
Re: (Score:2)
Re: (Score:2)
Or even worse, sites which think it's a good idea to prevent people from using automated password management/generation options...
I've seen quite a few security companies recommending this approach, and quite a few sites which do it.
Re: (Score:3)
Phone SMS is hardly better, especially as most regular people these days use the very same phone for browsing and for receiving SMSes. So it's not two-factor, it's a single factor, except that it gives juicy personal data to the website operator to sell.
Re: Ditch the password (Score:4, Insightful)
Lousy recovery procedures (rant warning) (Score:2)
But if I get all five answers correctly, can't the system let me in and do whatever is needed at the moment, and can the password reset be put on hold for a while, at least til the end of the session
Re: Ditch the password (Score:5, Insightful)
So your mother's maiden name could be an arbitrarily long phrase that's easy to remember but has no actual content related in any way to your mother's maiden name.
Re: (Score:2)
So then the "security questions" just become additional passwords.
Re: (Score:2)
So then the "security questions" just become additional passwords.
You're not wrong, but that's not necessarily a bad thing.
The sort of person who answers "What is your mother's maiden name?" with "euthanized carrots" is absolutely going to be storing that in a proper password manager. What's the scenario where a phishing attempt convinces that person to go unlock their KeePass database to figure out what absurd answer they used, without that person recognizing "something isn't right here"? That person knows what those answers are for; recovering access to an account w
Re: (Score:3)
Re: (Score:3)
Re: (Score:3)
My mother's maiden name is X5$'2su#nKu9)v=
What? It's a perfectly cromulent name on Omicron Perseis Two, you damn xenophobe!
Re: (Score:2)
Re: Ditch the password (Score:2)
Re: (Score:2)
The #1 problem in security is human interaction in any way. Humans are a security liability, no matter how you deal with them.
If you can somehow remove the human factor, you attain perfect security.
Reform the password (Score:2)
The new password policies in the article are good, especially with the focus on...
Nope. The whole concept of passwords is bankrupt, and largely because everyone has implemented their own version.
The password should be validated by the browser on the user's system and used to unlock a unique string that can be used as a password to the site.
For example, the MyBank.com site should ask my browser for the 64-character password, and the browser should ask me for a user-selected password that can be used to unlock the specific 64-character password used by that site.
The whole thing should be m
Yes throttle, no aging. (Score:5, Insightful)
>"Limit the number of passwords which can be attempted per time period."
That is WAY more important than anything else. Just a simple throttle or limit will defeat all attempts at brute-force. Ideally, X attempts (from anywhere) before a long delay. So the strength of the password won't really matter much.
The two WORST things you can do is:
1) Aging passwords. This does almost nothing to improve security. Instead, it just encourages picking the worst passwords and storing them all over the place (because they can NEVER be remembered) while making all users HATE your system.
2) Make the password requirements too difficult- too long, too complex, too many rules. Again, makes it too hard to set and too difficult to ever remember.
Both also unnecessarily increase the load on the admins who have to deal with lockouts and resets.
Re: (Score:2)
1. Limiting attempts has to be done in a manner that doesn't cause denial of service .. implement 2FA? If you must have passwords and can't rely on device auth alone.
2. Limiting attempts is good if you are blocking the top 1000 passwords (or more, depending on how many users you have and can block by IP).
Re: (Score:2)
DO NOT block by IP if you're still supporting IPv4.
There are a LOT of ISPs out there now using CGNAT where there are sometimes thousands of real users behind the same address. All it takes is for one user to be infected with malware to get the shared IP blacklisted.
Re: (Score:2)
Depends .. if your site is frequently the target of DDOS attacks by botnets .. something like Cloudflare plus blocking by IP works really well. For certain types of businesses, having a few pissed off customers is well worth it. You may anger or lose a low single digit percent of your customers .. but the tradeoff is OK .. for some (especially if it's not a B2B app).
Re: (Score:2)
That can be a problem for external, but it kinda depends on your user base. If you do lock out an IPV4, then it should only be for a short time- 5 min, 10 min, maybe 30 min. Enough to incapacitate botnets but not enough to deny access to valid users for too long.
Re: (Score:2)
This does almost nothing to improve security. Instead, it just encourages picking the worst passwords and storing them all over the place (because they can NEVER be remembered) while making all users HATE your system.
Actually, this historic and today entirely stupid practice universally decreases security. For example, the German BSI warns to not do that anymore. Yet, for example EY and other IT revisors still require it because they have no clue what they are doing. Why is this stupid? Well, it pisses off users, makes them use worse passwords, but the kicker is this: What attack does this actually prevent? Keep in mind that stolen passwords are typically used within hours or days on other sites. I do not know of a sing
Re: (Score:2)
These people are not stupid, and they are not wrong at the time, but they do not have the insight to see the flaws in their proposals. That insight only comes 10 years later, when the next bunch of people stand up and point out how all the previous forms of security protect
Re: (Score:2)
These people _are_ incompetent. Follow-the-ritual "security" without understanding is the hallmark of incompetence in that space. I knew 20 years ago that this was stupid. Why? Because I actually looked into where these 90 days come from. They come from historic UNIX passwd files that were world readable. The estimate was that breaking a password would take 90 days. Hence enforced change every 90 days. Now, shadow passwords are the standard for at least that long and with that the whole idea became obsolete
Re: (Score:2)
I actually looked into where these 90 days come from. They come from historic UNIX passwd files that were world readable. The estimate was that breaking a password would take 90 days.
Nah, they long pre-dated Unix passwd files. The rotation rules came from the mainframe world, originally. 30 days was more common than 90 days.
Re: (Score:2)
The theory behind password rotation enforcement (which, as you say, is wrong and bad for security) was twofold:
(1) It was thought to limit the effectiveness of brute force. If brute forcing takes two years to find a password with probability 0.5, because of complexity and rate limiting, than forcing a password to change every 90 days means that a brute forcer can only expect to find a password with probability 0.006.
(2) It was also intended to close the window of access. This isn't so relevant for cons
Re: (Score:2)
>"Yet, for example EY and other IT revisors still require it because they have no clue what they are doing"
Indeed they have.
More than once I had that fight. And I took it all the way up to the top and won. Aging passwords has *always* been a stupid practice These are the same "auditors" that insisted I should install MS-Windows "antivirus" on Linux servers and Linux workstations (sigh), long before there even was such a thing.
I do support locking logins after X months of no activity, however. Hopeful
Re: (Score:2)
>"No amount of salt and other security through obscurity can protect your password from a determined adversary once it's stored on someone else's system."
You are contradicting yourself. If it NOTHING protects it, then making it needlessly more complex also does nothing to protect it. It just makes it a lot more inconvenient for the user, and for the admins as well.
Note, I am not advocating tiny stupid passwords. But 8 characters that includes at least 1 number and at least 1 cap should be "enough" for
Re: (Score:2)
OK, that is a reasonable option.
Still, for those systems that do NOT do that, I stand behind my view that complexity overkill isn't helpful.
Even worse: Enforced timed password changes (Score:2, Insightful)
These are basically the worst killer of password security and no serious security catalog requires them anymore. In fact, they have started to warn to not do that. But tons of passwords still need to be changed regularly without any sane reason.
What is the root-cause for this? Simple: Cargo-cult security, i.e. doing the ritual with no understanding. Far too many "professionals" actually have no clue why they do things, they just do what everybody else does or what they think everybody else does.
Re: (Score:2)
My former security employers' and current university's IT enforced these password changes every three months or so. So annoying!
Re: (Score:2)
Indeed. I do what anybody competent does: Use an actually good password with a number at the end that I increment. But being forced to do that by these incompetent cretins pisses me off.
Re: (Score:2)
Ha, that didn't work. It tracks the patterns. :(
Re: (Score:2)
Ugh that's evil.
Re: (Score:2)
I've done that before, but after awhile you have to move to 2-digit numbers, and if your employer is goofy enough to have multiple services run off of different logins that have different rates at which they force password change, you've got to remember which service has which version of your unified password-with-an-incrementing-number-at-the-end-of-it and oh god it's awful.
Re: (Score:2)
Over 20 years ago my hosting provider forced password expiration for about 2 months until someone pointed out that was a bad idea. There's lots of published studies that show how password expiration is a bad idea. When I've worked for companies that required this I had to point them to the studies that showed that was a bad idea. Some change policy and some don't.
Along the same lines is requiring a new password to not be any previous password. This is a security problem too because then they have to sto
Re: (Score:2)
These are basically the worst killer of password security and no serious security catalog requires them anymore.
I believe the US Department of Defense still does.
Yes, I'm aware that the response is going to be that that just proves your point.
Re: (Score:3)
A lot of companies and organizations still do. All the big audit companies still require it. I have recommended several of my audit customers (I am internal audit as a service in this situation) to just get a risk acceptance from the company lead and be done with it. Not surprisingly, they all got that risk acceptance easily.
Cargo-cult security is really the worst. But apparently many people really think that way, even many people that are supposedly smart and educated and "experts".
Re: (Score:2)
Rotating passwords has its reasons, but in most places, those reasons simply don't apply.
Re: Even worse: Enforced timed password changes (Score:2)
Far too many "professionals" actually have no clue why they do things, they just do what everybody else does or what they think everybody else does.
Definitely true of the whole IT industry these days.
Re: (Score:2)
This is mostly just annoying. Just about everybody simply creates the password they want, and then add 1, 2, 3, 4, 5 etc., each time they are required to change it. Almost nobody comes up with a truly unique new password. So stupid, yes. Worse (other than the annoyance of having to jump through an unnecessary hoop)? Maybe not.
Remove SMS from the list of acceptable 2FA methods (Score:2)
Remove SMS completely. It's too easy to hijack. If you look at how it's implemented you'll also see that it's not necessary. Every SMS-based 2FA I've seen is based on TOTP codes. The infrastructure's there on the server side. Just present a QR code and secret code the user can scan or enter into their 2FA app and presto, instant replacement for SMS-based codes. At this point everyone who has a phone that can do SMS has one that can run an authenticator app (and if there's still ancient non-smart feature pho
Re: (Score:2)
Another stupidity around the use of TOTP codes via SMS is the complexity of the code. It would be much better to implement some kind of rate-limiting or time-based lockout than have 9 character TOTP codes, which are troublesome to take from a phone to a desktop browser. 4 character TOTP codes should be adequate with rate limiting.
Re: (Score:2)
The 9-character TOTP codes are typically 9-digit TOTP codes. That's no harder than dialling a phone number (remember when we used to do that? No?)
Re: (Score:2)
Alright, it's 9 digits. It's still unnecessary. It's security theater.
Re: (Score:2)
I don't use an app-compatible phone, so I prefer SMS.
Re:Remove SMS from the list of acceptable 2FA meth (Score:4, Informative)
Phones that don't run apps still comprise nearly 20% of the market. https://www.fool.com/investing... [fool.com] Your app-based solutio doesn't work for these people.
No SMS please (Score:2)
I hate that.
Neighbourhood where I live has very weak mobile reception.
A text may take over 2 hours to arrive.
It's insane.
Unless you leave home and walk up to some spot a with stronger signal.
I use a Desktop and landline. So not practical.
And now more and more utilities websites that I depend on are implementing SMS authentication
making life here very hard indeed.
Re: (Score:3)
Or when you're travelling and are using a local simcard, but your accounts are linked to your home card which you don't want to use because of punitive roaming charges.
Why do so many sites have passwords? (Score:3)
I think a more relevant question is why do so many sites have passwords at all.
I use the same crappy password on a lot of sites, because I really don't care if someone "steals" my account.
Re: (Score:2)
I think a more relevant question is why do so many sites have passwords at all.
I'd think the answer is obvious - those sites require accounts because they want to be able to track and hopefully monetize their end users.
Human nature (Score:3)
Passwords that require both uppercase and lowercase, a number and a symbol are actually not very secure due to human nature. I can't remember the exact study I read several years ago, but the conclusion is that most people do the following:
Capitalize only the first letter.
Follow the letters with a two or four digit number.
Place the symbol at the end.
The fact that so many people use that format vastly reduces the number of permutations a brute force attack has to test.
The classic xkcd is right [xkcd.com], in that longer is far better than allowing shorter passwords that require specific kinds of characters.
Re: (Score:2)
Why memorize something you can outsource to a password storage program?
Requiring complex characters isn't "bad", per se (Score:5, Insightful)
Unlike the first two listed entries, requiring complex characters doesn't create weak passwords... it just doesn't add much actual security.
I think they missed a significant one, though. I still run across sites that (via javascript) prevent a user from pasting into the password field. While many Slashdotters might be able to work around this, the typical end user will not know how. This idea was fairly silly even back in the day... but now, it definitely increases the friction for people who try to use unique passwords stored in an encrypted password vault (Bitwarden, LastPass, etc.).
Re: (Score:2)
Requiring complex characters forces people to create passwords that they later can't remember. That's a bad thing, because it leads to a password reset process which is often less secure than the login process itself.
Re: (Score:2)
If people are creating unique passwords for each website they access, they are not remembering all those passwords - whether they've used complex characters or not.
That's what password vaults are for.
Re: (Score:2)
The vast majority of non-technical users, have no idea how to use a password vault.
What we did (Score:5, Interesting)
Back when I ran an anti-spam software company, our customers had accounts for downloading data feeds, updated rules and such.
We did not let the customer pick the password. We generated a random (as in derived from /dev/random) 12-character password and they had to use that. We also didn't let them change the password.
If they forgot the password, we reset it for them, though this didn't happen often because the password was remembered for them in our software.
The advantages of this system were (1) the passwords were decently strong, and (2) if by chance our server was compromised, we had enormous confidence that it wouldn't lead to any of our customers' other credentials being compromised.
I realize this is not a scalable or attractive solution for many cases, but it worked well for us.
Couple things... (Score:2)
1. Additional requirement for password systems: "the system will accept and validate for login any password that it will let you set"
Dumbest thing in the world that the set-a-password acceptable characters fail when logging in. I've run into this a number of times.
2. That, and plenty of other dumb password things happen because teams of developers implement password security themselves, again and again, without any domain training, reinventing the wheel and making all the basic mistakes over and over again.
Showing clear passwords by default? No thanks (Score:2)
For crying out loud, nobody is looking over my shoulder! Make the "unhide" default.
1. I'm so glad to know nobody in your sphere is malicious. I'm also glad you never have do demonstrate anything that happens to require a login at some point.
2. You may live in a sparse country, drive a car, have your own bedroom/house, work in your own office. But are you going to tell someone in India that they don't need password privacy?
Dots (Score:3)
For crying out loud, nobody is looking over my shoulder! Make the "unhide" default.
I don't really agree with that one.
When I'm doing some kind of online collaboration, I try to make sure that any passwords I type are on a different screen than the one I'm sharing, but sometimes I forget which screen it is or that I haven't turned sharing off. Few of the people I've worked with even go to that much effort.
Everyone who happens to be in on online screen sharing meeting is in fact looking over your shoulder. Without the dots on by default, I think there would be a great deal of additional password leakage in the real world.
Idiots Abound (Score:3)
My favorite is when I go to autofill a generated complex password and it rejects it because only certain special characters are allowed... like I can't use single quotes or greater than/less than symbols for some reason. Makes me hope they are actually hashing the password before it goes to the database...
Also when a site has an arbitrarily low maximum password length. I like to use a password that's 16 characters long, but for some reason some sites limit you to 12 for no apparent reason.
The root of all of these are bad password recommendations designed to appease clueless accountants during a compliance audit, and hope you get it right the first time because it's never going to change after that.
Ultimately, though, I feel it's the user's responsibility to use a good password and if they don't, well, too bad. I'd like to see more blame placed on the users here.
But WHY? (Score:2)
The article asked WHY so many sites have bad password policies. It doesn't seem like most posters are addressing this question.
2FA is not a password policy (Score:2)
"Pair the password with a second authentication factor such as a security token or cell phone sms. Require both to log in."
I'm so fucking sick of this. This isn't a password!
"We put all these requirements on your passwords, and you need a text message to log in. Actually if you forgot your password we'll just send you a text message. Huh, wow, looks like all the hackers are SIM spoofing to receive text messages meant for you, sorry about everything getting stolen oopsy well we did everything by the book
Re: (Score:2)
Re: (Score:3)
Erh... password hashing algorithms are already free for anyone who asks. Including the algos to add salt and pepper. What exactly is your point?
The problem isn't that the algorithms are not available or that the "process" is a closely guarded secret. It isn't. The problem is that with available cloud computing, it's trivial to break trivial passwords, then use them to do some password stuffing attacks against these people's mail accounts, where they used the same passwords, then go around various sites and
Re: (Score:2)
Get a password safe.
Re: (Score:2)
fan website--no
You say that now, but may I remind you of that when the police knocks at your door and wants to know why you post those things promoting Islamist terror attacks on the fan page?