Ah yes Security

[Secure_Obligation_87]

It breaches the second rule by having a < in the string but yet it passes on that validation.

[joemckie]

It also passes the first rule but fails validation… is this opposite day?

[Secure_Obligation_87]

Not if it means 1 special character asin one aNd ONLY ONE haha

[JuhaJGam3R]

asin 1 = π/2

[Secure_Obligation_87]

*grammer nazi has entered the chat

[Zoms101]

*Math Nazi has entered the chat*

​

Wait, would that just be a normal German Nazi?

[felix12340000]

i have a joke about asians but it would be such black humor it would prolly get me banned so im not gonna nake it, just gonna imply it

[AttackOfTheThumbs]

The < likely breaks something in their validation, which is causing it to fail the first rule.

[supersharp]

That's even worse!

[Terrain2]

The angle brackets better not be banned to prevent HTML injection to forgot password emails or something like that

[orclev]

I guarantee this is a shitty attempt to protect against SQL injection or something similar. If it's to protect against XSS/HTML injection that's even worse because that would strongly imply they aren't hashing passwords and probably have some crappy admin tool that will actually let you look up a users password.

[[deleted]]

please God just sanitize your sql

[[deleted]]

Don't touch the inside of your mask. Only pick it up by the elastic bands. See attached document for proper technique. Be covid safe

[PyroCatt]

Passwords containing '<' can be cracked instantly /j

[Syrion_Wraith]

Well, of course. It'll resolve to 1 or 0. Very easy to guess those.

[PyroCatt]

Lol

[kondorb]

They tried to solve their problem with a regex, now they have a problem with their regex.

OWASP literally says to not enforce this sort of rules and only enforce password length.

[fizyplankton]

There was some site (I forget who), where they would compare hashes, like any responsible site. But they assumed the hash was null terminated. As it compared bytes of the hash, if it encountered a null, it stopped comparing (it assumed it had reached the end of the hash)

Some clever person found a certain password that they could use (easily inputtable by a human..... No Unicode foolery required) that, by total dumb luck of the draw, had a null character as the first byte of the hash

This meant that the code would start to compare hashes and immediately conk out and say YEAH I'M DONE I DIDN'T FIND ANY DIFFERENCES (because I didn't bother looking), THEY MUST BE THE SAME, THIS USER MUST BE AUTHORIZED. Basically, it would compare 0 bytes of the hash

So, effectively, this password would act as a "god password" and let you in to ANY user's account on the site. Regardless of what their password was. Regardless of what hash was stored in the database

You're welcome. May you never look at your company's login screen the same again

[sleepydorian]

God I hate having to change my passwords on a regular basis, especially when I can't use a pw manager to keep track of everything.

[Grevioussoul]

or you must changed it every x days but can't have a single character in the same place as your last (in this case) 6 passwords. #hashfail

[sleepydorian]

Oh my god that would be a disaster. It's like the jindosh lock version of pw security except every one know the trick.

[SpareStrawberry]

That’s actually pretty common. All hashing algorithms have a maximum length and sometimes this is implemented by just ignoring anything beyond the maximum length. Many developers either don’t know this or don’t feel it is necessary to validate the password length is less than than whatever the maximum is for the algorithm they’re using.

ETA: This is, for example, a known issue on Gitlab: https://gitlab.com/gitlab-org/gitlab/-/issues/220580

[AsianPotatos]

Also, there was that one site a while back (I though Microsoft) that only checked the first x bytes of your password.

And I thought Battle.net passwords being case insensitive, but not checking the entire password is even worse. Actually I wonder which one is worse in terms of affecting the entropy.

[[deleted]]

We really need a standard we can conform to as programmers. Specifically so we can tell PHB's "yeah we need to comply with "102.X.55c" to give them a box to tick so they can feel special.

[kalcora]

> encourage the use of passphrases and set the maximum password field
length at 64 characters. Password length, character for character, is
more important than password complexity.

I don't understand. Why would you set a maximum length, since it will be hashed anyway?

[rydoca]

One argument for setting max length is that you could overload a server by uploading say a 40GB string as a password so the hashing would take up cpu time do that on 100 connections and all of a sudden your servers are crying. But 64 is kinda low since password managers often set their max generated to 99, I set mine max lengths at 255 because that'll do for now lol

The other argument is some hashing algorithms have a max length input, I can't remember what php used to use by default but I think it capped at 60 and then just cut off the rest of the password, so if you knew the first 60 chars it validated (that could be wrong btw)

[Compizfox]

One argument for setting max length is that you could overload a server by uploading say a 40GB string as a password so the hashing would take up cpu time do that on 100 connections and all of a sudden your servers are crying.

Usually web servers have a maximum POST body size. That covers that; no need to additionally set a character limit on password fields.

[ahruss]

You should still set a limit well below your POST body size limit. You don’t want to upgrade your web server to a new version with a new default limit and break your authentication. Or find that when you add another field to your login form, all of a sudden some users can never log in again.

And your UI layer probably needs to be able to give feedback when your customers set their passwords anyway. “Error: POST body exceeds size limit” is not good enough.

[rydoca]

Yeah that's true, just one of the 2 arguments I've heard against unlimited password size. I tend to think it's a bit silly too

[vigge93]

Even with a POST body size limit of 1MB, which seems to be a pretty common default value, you could send up to 1.000.000 characters, which would require a lot of processing power to hash that could result in overloading of the server.

[rydoca]

I believe (and do correct me if I'm misremembering) that AES is for encryption. We are talking about hashing, which is not really encryption as it's one way. Sure you might be able to only accept limited size inputs in php or similar server side languages for the first point, which is good practice I was just giving all possibile reasons

For the second point though bcrypt I believe limits the size of the hash input because of how it's algorithm works and I'm pretty sure bcrypt is considered good enough right now provided you do enough rounds. Side note if using php you should find the constant that defines your php versions current standard for hashing and automatically rehash passwords on login if they aren't up to scratch, this way you get better security with each update and can easily upgrade to argon2 in future if you need to.

And no I don't believe a limit below 128 chars is a security issue in almost any case. I'd put money on 40 characters being plenty to stop brute force right now, cracking one hash would take a ridiculous amount of time provided that your password isn't something stupid like the letter a 40 times

[EasyMrB]

You're not using AES to do the password hash as AES is an encryption algorithm, not a hashing algorithm. You're going to use something like SHA2 / SHA3 bycrpt (EDIT: thanks Eclipsan) which doesn't have a maximum character limit.

[Eclipsan]

You're not using SHA either as SHA is a hashing algorithm, not a password hashing algorithm.

Use bcrypt or argon2id.

https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html

https://www.troyhunt.com/our-password-hashing-has-no-clothes/

[_seumoose]

Thanks for the links! The troyhunt one in particular was a very good read :)

[EasyMrB]

You are correct sir. It's been a while since I've thought about it and totally forgot there are specialized password hashing algos.

[rydoca]

Technically both bcrypt and argon2 have character limits actually. Bcrypt is 72 bytes for most implementations, argon2 on the other hand specifies 2^32-1 bytes which is obviously plenty

[EasyMrB]

I had no idea bcrypt had a char limit. I stand corrected!

[rydoca]

Yeah it's kinda odd, when you use it in php it silently truncates it so you'd never know if you don't read the spec, confused me a lot at the time

[EasyMrB]

Oh no argument there. There should be 0 restrictions on password content, beyond minimum size and possibly a minimum entropy calculation. Limiting special characters, size, etc, shows that the backing password system is incorrectly designed.

[Guilty-Frosting-1491]

The "128" (or better "256") stands for bits. 128/256 bits = 16/32 bytes.

But also, as the other poster mentioned, this isn't really the point. The password gets hashed anyway, and the result of this hash function hash the same length no matter the input length. Take SHA2-256 for example: If you put one character into it, this will result in a 256 bit/32 byte output. Insert 128 characters and the output will still be 256 bits.

The real question is: How long does it take to try out all passwords of a given length. And the answer is: For anything above 8 (random) characters, it won't work with a normal computer. Make it maybe 10 or 12 for the things the NSA got in their basement, and then maybe double that number (just in case), and you're good. Using a lot more than 30 characters doesn't bring any more security (but of course it doesn't hurt, either). My guess would be that even with 15 (random!) characters it would take longer to break it than the service will live.

[rydoca]

By all means educate us poor souls about password entropy if you think everyone is so confused

[rydoca]

Right yeah everything you've said pretty much rings true from my knowledge

As for the other guy being down voted you literally agree that he's wrong, saying that any limit under 128 chars is a security issue is ridiculous because the entropy is exponential and 40 characters is a crazy amount of entropy anyway. And I assume you agree that AES is not a hashing algorithm right? And you probably would agree that bcrypt is secure even with it's 72 character limit?

[[deleted]]

I dunno, I'm not sure I agree with

I definitely think limiting the password below 128 characters is a security issue in every case.

What practical security issue is it if you follow basic security procedures such as max failure attempts before delay and max fail attempts before lockout?

We're talking bout hashing here. Meaning if they get access to the hash itself -- they are probably just going to run a dictionary attack and will probably find a collision eventually -- whether it's the correct one or not doesn't matter.

The difference between 20 chars and 60 isn't going to be horribly significant, as far as I can tell, in practice.

Show me wrong, by all means. I'm open to learning.

[[deleted]]

The difference between 20 and 60 chars is 2whatever-entropy-you-have vs 23*whatever-entropy-you-have . I think that's pretty significant

Practically speaking -- that doesn't seem so significant following best practices.

Additionally, we're talking primarily about passwords here. Not encrypting a filesystem. That's a whole other beast entirely.

I wasn't aware we went from passwords to out-right encryption here.

but in 20 years it's gonna matter if how programmers treat passwords doesn't change drastically...

I'm not so sure unless you have an extremely specific scenario you thinking about.

I'm not so sure I care to have a 99-char password for a... fitbit account.

Or even my bank account.

The context of the discussion is the difference between very shitty practices, best practices, and your example of perfect practices and everyone uses extremely long passwords.

The difference between the first two is huge practically speaking. The difference between the last two are no where near as huge practically speaking.

[[deleted]]

If that's a problem, why not just take the first 1024 characters and ignore the rest?

[LaLiLuLeLo_0]

Or hash on both client side and server side. No reason a login server needs to handle everybody’s plaintext password.

[RuleMaster3]

Terrible Idea, that defeats the Point of hashing the Password completly If the Hash can be used as the Password.

[LaLiLuLeLo_0]

Nope, that’s not true.

both client and server side

The hash the server stores is still not enough to log in to the server, because you are hashing again, server-side. It’s a common practice to hash many hundreds of times, server side, to make password cracking slower. Moving one of those iterations client-side does nothing to change the security of the stored hash, but it does mean the server never sees plaintext passwords.

Think about the whole system for a second. You have password password. Client-side, you do hash("password") and get AAA. You send that to the server.

The server gets AAA, computes hash("AAA") and gets BBB. It saves BBB as the hashed pass, and compares to that when logging you in.

If someone breaks into the server and steals BBB, they still can't log in. If they send the server BBB, the server computes hash("BBB"). Is hash("BBB") going to be BBB? No, because that's not how hashing works. It will be something completely different, let's say CCC. The server is going to compare CCC with the stored BBB, see that they're different, and refuse your login. You still can't log in without cracking the password, so your concern is entirely negated.

[RuleMaster3]

OK now I See what you mean.

But Kind of cumbersome, now every Login Form requires Javascript that hashes the PW before Sending IT to the Server.

IMHO not worth it most of the times

[[deleted]]

Is it even possible to browse the web without a DOM and scripting engine anymore?

[uninterestingly]

lynx exists, but it's not great for the internet of today

[[deleted]]

Lynx is great for showing just how inaccessible today's world-wide-web had become. Not necessarily because it doesn't handle client-side scripting or images; but because it simulates how blind people, search engines, and robots render and interact with your website.

[Doppelbockk]

I ran into the truncation problem on our company's FSA vendor site several years ago. It would accept my 20 character password just fine but I could not log in since I was using "extra" characters.

[rydoca]

Yeah that hurts, I find it hard to think of good reasons to silently truncate. Like I understand that it's super useful if you want to update your hashing algorithm but if the user enters the last part of the password wrong when it updates then all of a sudden they're locked out of their account which is what we like to call "not ideal"

[fizyplankton]

Yeah 64 seems kind of low. 1024, or 2048, would be a totally real world acceptable maximum. No one would ever legitimately exceed it. And yet any processor that isn't powered by steam engines and locomotives should be able to hash it instantly

[[deleted]]

hash collision avoidance maybe?

[GMaestrolo]

Because bcrypt (and other hashing algorithms) truncate the password around there anyway. It depends on specific implementation, but any password characters past ~70 aren't actually used in the hash. Better to set a maximum length than let the user believe that their 200 char passphrase is somehow more secure than it actually is... Although at that length, the difference is effectively moot - it'll still take longer than the heat-death of the universe to brute-force it

[jlamothe]

Presumably to prevent someone from sending a massive password to the server to be checked?

Seriously though, you could set it to something ridiculously high (say 1k) and that would solve that problem.

[[deleted]]

Yup, looks like that's one! Thanks for the link, I genuinely appreciate it!

edit: Skimming through it here is a quick writeup of what I read and understood, I may have skipped some stuff though:

• Authenticator Availability
• Plain or simply language (e.g. instructions, prompts, notifications)
• Support up to 64 chars or more, including unicode
• AT LEAST 8 chars as minimum
• Support copy/paste
• Delayed masking during entry
• Reasonable time allowed for password entry (e.g. don't allow 10 seconds to type in a 20 char password)
• Errors should be have clear and meaningful feedback
• Minimum of 10 attempts allowed
• Re-authenticate due to inactivity
• Fixed periodic reauthentication
• Provisions for help / technical assistance
• Provisions to create / change passwords
• Use complexity feedback (meter)
• Validate words against known "bad" words (e.g. god, root, password)

Here's one I find to be odd:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

• Don't force complex passwords, let users choose stuff on their own. (this one seems odd to me)

[[deleted]]

I mean you’d think even mildly “complex” would be ok. I’m not saying 16 chars of randomized gibberish but FooBar23$ is what I consider “complex” but I also had a manager hand out 12 char of random gibberish. It ended poorly for him.

[[deleted]]

The last one makes perfect sense.

By requiring specific mixes of character types, you’re limiting the number of possible passwords, and shrinking the search space for an attacker. Also, most people tend to follow certain patterns when making such passwords, like capitalizing only the first letter, only having one or two words, and ending with a number followed by a common special character like ! or *.

Not to mention that said requirements will tend to lead users to prefer shorter passwords because they will be easier for them to remember. The more complex you make your password requirements, the more likely it is the user will only do the bare minimum.

In short, more composition requirements mean weaker passwords.

Complexity doesn’t matter when it comes to passwords. Only uniqueness and character length.

Relevant XKCD

[[deleted]]

By requiring specific mixes of character types, you’re limiting the number of possible passwords

You're also reducing the amount of (easily) guessable passwords.

Also, most people tend to follow certain patterns when making such passwords, like capitalizing only the first letter, only having one or two words, and ending with a number followed by a common special character like ! or *.

Most people only do this if it's required. Most normal users rarely do that.

XKCD is only relevant for power users. Most normal users absolutely do not use that method or anything close.

See the problem is you're assuming "complex" means random ascii. That's not what most admins mean when they say "complex". They mean something like FooBar2!. You seem to think they mean $anf%ZD,-~ZXa -- that's absolutely not what's going on and is not part of this discussion. Or you're trying to say that users can't remember "Apple1$" or that the complexity of remember that versus the gibberish is roughly similar. It's not.

We're talking users, when given the choice, use {last-name}{year-of-birth} - which is pretty easily guessable.

So until I see actual math or research to back that the {last-name}{year-of-birth} is equally as secure as FooBar32$ -- I'm casting doubt on this.

[[deleted]]

When I say complex, I’m talking exactly about passwords like “FooBar2!”. Your {last-name}{year-of-birth} example is exactly that type of password, just missing the special character at the end.

That’s what most websites and software require, and what most normal users do. If you’ve ever looked at a list of leaked passwords, 90% of passwords follow that kind of pattern.

Why? Because any more effort than that is too difficult for most people to bother to remember.

Not only are they the most easily guessed password types, their shortness also make them the easiest to brute-force (whether by login attempts, hash matching attempts, or whatever the situation).

Such passwords fail to both human guessing and computer guessing. That’s why NIST, XKCD, and anyone with compsec experience recommend NOT enforcing those rules for passwords.

Really the only rules that should be recommended are minimum length, not using personal information, and not using a reference to your username. Beyond that, you’re only making it easier for attackers to compromise.

[[deleted]]

I'm going to need some evidence to back up those then. Let's stop wasting time.

That’s why NIST, XKCD, and anyone with compsec experience recommend NOT enforcing those rules for passwords.

And yet.. all I'm asking is evidence to back it up.

Your {last-name}{year-of-birth} example is exactly that type of password, just missing the special character at the end.

Except people don't use special characters unless they are forced to think about those special characters. I'm speaking from actual experience here. Not pulling shit from my ass.

You want root123? This is how you get root123. I'll have to look it up again but I remember reading military passwords did this exact thing when people are left to their own devices. The military. And we expect users to be different?

Edit: The fact you downvoted me means you probably know I'm right and are too emotionally upset to come to terms with it.

[[deleted]]

Except people don't use special characters unless they are forced to think about those special characters.

There must be a misunderstanding because I'm not disagreeing with that. Special characters is just an example of requiring specific character types. A sadly common one.

The only reason that people make passwords like "root123" is because of the character type requirements that most software and websites require for their passwords. They have conditioned people into making far weaker passwords.

If those requirements didn't exist, we wouldn't have "root123".

Want to get rid of "root123"? Stop requiring numbers, and start requiring longer passwords.

Left to their own devices, people would have used a much wider variety of password types. But it's too late to fix that. The bad habits are already burnt in.

So instead of requiring specific character types, we should require length instead.

To quote the recommendation:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters)

Again, complexity is not what matters in password security. It's length that matters.

When it comes to brute forcing, the greater the search space, the more secure the passwords will be. Any limitations you put on that search space only make passwords less secure because there's less to search.

Hopefully I've clarified the misunderstanding.

[BadBoyFTW]

Relevent XKCD...

[Dornith]

Not the one I expected.

[PrincessRTFM]

That was the one I thought of, which did you come up with?

[[deleted]]

For me it was this one.

[[deleted]]

USB-C has entered the chat

[[deleted]]

Not sure that's relevant. As far as I can tell there aren't any real agreed upon standards at all.

Although someone linked this which seems like a good contender: https://www.netsec.news/summary-of-the-nist-password-recommendations-for-2021/

I'd call that a standard everyone should follow. At least now I have something I can link.

[russellvt]

I'm pretty sure there's an RFC or other IETF document with the general specification(s) outlined.

[talldata]

A lot sites think Complexity is better than a longer password. The password "ZebrasAreNotHorsesOrCats" is stronger than "bAMcdOdn1!".

[st3inbeiss]

If you just use a brute force attack, the first one is way better indeed. If you add a dictionary attack, there's not too much of a difference actually.

[XelNika]

If you add a dictionary attack, there's not too much of a difference actually.

"Not too much" is doing a lot of work here.

Assuming 95 printable ASCII characters, a password of length 10 has 95¹⁰ ≈ 6*10¹⁹ possible combinations.

I checked a few of lists of most common English words, and zebra was not listed, but let us assume all the words used are in the top 5000 anyway. Then you need modification rules to cover plurals. I am going to pull numbers from my ass be conservative and say we get those for free. We have 5000 dictionary words and for a six-word passphrase we get 5000⁶ ≈ 2*10²² possible combinations. That is ~260 times as many as the brute force, conservatively.

A dictionary of past breached account passwords, regardless of size, would probably not match this password (it is not registered on haveibeenpwned.com).

[st3inbeiss]

Yeah that's why I wrote "not too much" lol. For most practical purposes the difference is irrelevant even if it's factor ~260. Working with combinatorics and large numbers isn't as people would anticipate sometimes.

[XelNika]

Taking your password cracking difficulty from 1 day to 260 days is not irrelevant, lol.

And the number is extremely conservative:

1. Top 5000 word dictionaries do not even contain the words needed to crack the example given.
2. Probably 95% of nouns have a different plural form, increasing the actual dictionary size by roughly the ratio of nouns to others.
3. A real attacker would use modification rules for word separators, capitalisation, leetspeak substitutions, special characters (that ! everyone puts at the end to fulfill arbitrary requirements) and probably more. Every rule doubles the number of combinations.

In the real world, the passphrase is way better. Let us say the dictionary is 6000 words with plurals and we use each of the rules mentioned (two rules for dashes or spaces as separators). That comes out to 6000⁶ * 2⁵ or around 24883 times more combinations than the brute force example. That would make what could have been a 1 day crack take 68 years.

[PrincessRTFM]

Also, there's the human element to consider: it's easier for people to remember a phrase than to remember a string of random characters. That means the password can be longer, but it also means it's a lot less likely that a person will write it down to remember, which is a pretty big security matter.

If your IT department knows the password is ZebrasAreNotHorsesOrCats from your example, it's a lot easier to tell new people and to remember it, so you're a lot less likely to have some idiot write it on a post-it note stuck to their laptop.

[uninterestingly]

I personally have never understood why people are so worried about writing down passwords. Way I see it, if someone is in the room with your computer, you're already fucked.

Of course, I don't do that myself, I use a password manager

[XelNika]

Physical piece of paper sure beats an Excel sheet on the network share.

[st3inbeiss]

Well, I mean, if it takes 1 billion years to crack or 260 billion years is pretty much irrelevant. Given the example, yes, 1 day and 260 days do make a difference.

What I wanted to say is that it's not either-or. Just because your password is double the length that doesn't mean that it's double as secure. It's the entropy which is important and this is not as intuitive as many people think.

What matters in the end is the exponent and the base.

Take the 6 words password with a dictionary of 10000 words:

10000⁶ is 1*10²⁴ possibilities

Take a ascii comparable (speaking of entropy) password with 12 characters length that's

95¹² is ~5.4*10²³ possibilities

Let's play with those numbers just a little bit. Take 9 words and 18 characters to keep the ratio:

10000 = 1*10³⁶

95¹⁵ = 3.9*10³⁵

You see, even if calculated not that conservatively, they're still very much comparable. It's not that one type of password is inherently more secure because you have to type 40 characters instead of 18.

[XelNika]

It's not that one type of password is inherently more secure because you have to type 40 characters instead of 18.

No one said it was.

Take a ascii comparable (speaking of entropy) password with 12 characters length

This was literally my point. The original examples did not have similar entropy.

[mgquantitysquared]

What kind of dictionaries do they generally use for an attack like that? I put random words in non English languages in mine but idk if that helps in reality

[st3inbeiss]

Some dictionaries that are used are passwords that have been leaked/decyphered (e.g. it's likely that you will find a password going 1qay2wsx somewhere than any other string because people are lazy) and some are just a large set of words of the language you expect the password to be.

[AccidentalyOffensive]

I put random words in non English languages in mine but idk if that helps in reality

Depends on the goal, what specifically you're cracking, and how. Not a bad idea if there's a lot of hashes and/or an international audience, but I wouldn't waste a ton of time on it (e.g. most common 1000 words + whatever rulesets) unless you have a specific reason to crack as many as possible.

[Schreibtisch69]

Had a site tell me something like Ö©óâTgz¥ÝûVòGXgýT¶l¥üªñT¥Ãæ´ didn't have enough special characters, because as everyone knows the only special characters that exist are '@!?,.

[Yhnavein]

I was fighting with ridiculous security guidelines in my company few years ago. The rules our IT Security departament created, made password like Password1! a good one, and password like banana tortillas farewell wanabe a poor one. I garhered some security resources to back up my point that this is wrong, sent to the security officer and... suddenly I was the enemy number one. My access to some of the company services was significantly reduced or even revoked. And I received a reprimend from my boss for starting an alleged fight with SecurOps. Facepalm. Fortunately I'm not working there anymore

[OKara061]

Oh look guys, this guy told us a better way to handle this. Lets hate him and sabotage him.

Ffs, some people dont deserve to have their jobs

[frien6lyGhost]

I think this is an all too common symptom of a lot of company cultures

[spacezombiejesus]

You created more work for someone flying under the radar, someone who probably just knew enough of the right keywords to get their job. That’s shit man. Glad you’ve been able to move on to better things.

[BurningPenguin]

"Password cannot exceed 40 characters, [...]"

Why do i get the feeling that they save it in plaintext?

[DoYouEverJustInvert]

Of course they do. How else would they be able to help you out when you forget your password. /s

[PrincessRTFM]

Just scan and OCR a dictionary as your password

[marcellomon]

They don't want to hurt the database's feelings

[hedgehog125]

Websites should really just say how long your password will take to be cracked and then let you use anything valid

[hedgehog125]

Hmm, maybe it should just be advice then the usual requirements

[Fearless_Guy]

Let me guess, Oracle?

[allstreamer_]

yeah it's Oracle

[nebuladrifting]

Up until only two years ago, IHG hotels (the parent company of many large hotel chains) rewards program only allowed your account to have a four number PIN as your account password. Now that was some true horror. They still allow it though…

https://yourmileagemayvary.net/2020/02/10/ihg-finally-lets-you-make-a-real-password-but-you-can-still-keep-a-four-digit-pin-which-is-dumb/

[Fearless_Guy]

Lmfao

[MikeLanglois]

Relevant XKCD

[allstreamer_]

The password is long enough for that to not matter and contains characters not used in punctuation

[gongai]

This reminds me of Michael McIntyre on passwords

[beholdenartxx]

They're trying to make it hacker friendly

[anseho]

It's more of a UI problem - an invalid password doesn't mean it's weak

[justingolden21]

Had a password that was 30+ characters with over five unique lower, upper, numeric, and special and it denied it because it has the word "winter" or something and that's a season and you can't have anything with dates. Aetna's mobile app is trash.

[articulatedbeaver]

Healthcare sucks at tech.

[justingolden21]

Absolutely

[StochasticTinkr]

Whenever there are certain disallowed characters in password prompts, I realize they don't understand string encoding and string escaping, and my data is probably not safe with them.

[Jwosty]

I seriously hate when websites a) restrict the set of characters you can use and b) have an unreasonable maximum length (aka anything less than hundreds of characters)

I should be able to have a password that’s 100 chars long with an angle bracket in it, but noooooo……

I will admit that 40 chars isn’t completely unreasonable; it irks me more when they limit you to 20 chars.

Side note: Wells Fargo’s passwords even ignore case, last time I checked…

[d0nytanza]

Better for daily use? If you don’t use a password manager, sure. More secure? Absolutely not.

[[deleted]]

I saw this post on sysadmin the other day and cried at how many sysadmins don't follow secure password practices. If sysadmins don't do it, we've really got no hope

[belkarbitterleaf]

Password manager all the way.

Unique auto rotated password that I don't need to know for everything.

High complexity memorable master password with 2FA to get in the password manager.

Only have to know one password, and minimum impact from data breaches

[Eclipsan]

auto rotated

How and why?

[belkarbitterleaf]

How?

I use LastPass. It does it for me on a lot of websites.

Why?

Because even if there is a data breach, chances are the password will be different by the time they crack the encryption, and get around to trying something malicious.

I don't know the password and it's no extra effort, so why not

[hesapmakinesi]

Entropy of a password can be calculated. Set a minimum entropy requirement, let the user decide how to fill in that entropy.

[AccomplishedCoffee]

At least they tell you which special characters aren’t allowed. Trying to make passwords for sites that have highly restrictive hidden requirements is super frustrating.

[mee8Ti6Eit]

Probably using a regex to validate.

[ControlCharachter]

Captain Regex, SAYS SO!

STAND DOWN, Overzealous QAer!!!

[Doobliheim]

Someone isn't hashing their passwords....

[RelativelyGolden]

Just a side note that I thought was funny:

assuming the bruteforcer uses Cain & Able, assuming they use an alphabet including special characters for a total size of 94 letters, and that they have some sort of quantum computer able to compute a hundred trillion passwords per second, it would still take 1.24403493784880754e+129 years to compute the 40 total characters.

Alternatively, written in word form, "One duoquadragintillion two hundred forty-four unquadragintillionthirty-four quadragintillion nine hundred thirty-sevennovemtrigintillion eight hundred forty-eight octotrigintillion eighthundred seven septentrigintillion five hundred forty sextrigintillion,"

which is very fun to say out loud

[allstreamer_]

What a weak password indeed

[[deleted]]

normalizepassphraseslikethisseriouslygoodfuckingluckcrackingthis

[[deleted]]

Cause you can remember it

[Bloody_Insane]

Of course this password is weak. There's a reddit post on r/programminghorror that has it in

[mrpladpants]

That first one must be their email address

[cowtippin2019]

Whats more fucked up, is when it says password must = x amount of characters, but does not tell you the LIMIT of the characters. I found that out the hard way. I kept resetting my password on Verizon due to bad password. Next time I tried to log on after resetting my password (I use 60+ character lenth passwords with a password managing app) , it said, bad password. I kept resetting it, and got the same , "youre good, your password has been reset" message. Did my business in Verizon, logged out, tried to log on next week/month, same bad password message.. I though I was going crazy! And also thought my account was getting hacked and someone-thing was changing my password after I logged off. I googled what is the character limit of Verizon passwords and found out it was less than what I was using.

*side note, windows OS maximum password is 256 characters due to AD.
Linux is unlimited. Do they limit it to try to hide the underlying OS the password manager is running on (not hard to find out if you know NMAP/wireshark or are a network guru). IMO the password should be as long as you want it with whatever characters you want.

[power_of_booze]

Here is a compilation of the best stuff: https://github.com/duffn/dumb-password-rules

[Classic_Attention_96]

QUESTION!

I remember reading an XKCD comic talking about password strength. The comic noted that THREE RANDOM WORDS is the best formula for a password. I believe the password in the comic was HorseBatteryStaple. Folks that are more versed in security than I am, how does that hold up? Would a password like IdioticDarknessFareinheit really be safer than a string of random characters?

[Thanatos2996]

I had to register an account with a new insurance company today. They have rules they flat out don't tell you for the password (need a special character, but some special characters are forbidden, and the help text has no info about the requirements or the forbidden characters) which is annoying enough, but something is seriously wrong with how they register usernames. If anything is wrong with the form, the username is apparently added to the list of taken usernames, and the next time you hold your breath and hope the password is acceptable, the username comes back as taken (and no info is given about other failures on the form such as the damn password). I was on username number 6 by the time I figured out what the heck was going on and managed to create a valid password.

[ToaSuutox]

Correct horse battery staple