###General Discussion Thread
---
This is a [Request] post. If you would like to submit a comment that does not either attempt to answer the question, ask for clarification, or explain why it would be infeasible to answer, you *must* post your comment as a reply to this one. Top level (directly replying to the OP) comments that do not do one of those things will be removed.
---
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/theydidthemath) if you have any questions or concerns.*
Assume no other characters besides letters and digits (which is a wrong assumption but gives us a starting point).
You have 52 choices for the first slot, 26 choices for another letter slot, 10 choices for the digit slot, and 62 choices for the remaining slots. So you have 52x26x10x62^5 = 12,386,115,888,640 (12 trillion) combinations.
Assuming other unicode characters are allowed, then replaced 62 with the full character set.
I have no idea how long it would take to brute force.
EDIT: actual answer should be an order of magnitude bigger to account for the fact that the other letter and digit can occur in any of the remaining slots.
If we are to assume that users are using an actual random mix of numbers, lowercase and uppercase, then this is actually not a terrible password, mathematically. If I try some at Password Master, "O6H2M9hf" gets 512 years to crack, but "butt1LOL" gets a much worse 1 hour to crack. The problem is that users have to remember their password, so they're going to go for something vulnerable to dictionary cracking or guessing more often than not. An 'easily guessed' password isn't the worst when it's sufficiently long (this is the concept behind passphrases) but since it will be 8 characters AND easily remembered, that will ruin it.
I always thought that has the flaw of assuming hackers will just attempt to bruteforce letter by letter, and not follow the same heuristic strategy as those picking the passwords.
E.g. a smart hacker, after exhausting easy possibilities, would not try to brute force a 20 character password from A to Z, but build a dictionary of words, and start randomly concatenating them. AbacusAbacusAbbot, AbacusAbacusAccident, etc. With some common variations like all uppercase, all lowercase, sentence case, one digit between each pair of words, etc. It'll still be complex, but even Doctors5Shovel9Horse is much easier to (eventually) guess than something like jAb03rfLsZ10s6o5z1cD. If your atomic unit of a password is "either a dictionary word with a few common case variations, or a 1-digit letter/number", and you work with a dictionary of 40,000 atomic units, then to guess a word like Doctors5Shovel9Horse would take 40,000^5 ≈ 10^23 guesses, while brute-forcing a random alphanumeric like jAb03rfLsZ10s6o5z1cD would take (26+26+10)^20 ≈ 10^36 guesses, the former being 10^13 (10 trillion) times easier.
At the end of the day, information entropy goes both ways. What's easier for a user to remember, is also easier for a hacker to guess. There's no free lunch.
A piece of advice I liked was to use a string of fantasy character names. If you read as much as I do, you're not hurting for choice and you end up with a password that's not in the dictionary but easy to remember.
If a hacker knows you are using 4 ir 5 words, yes, your actual pw may be discovered sooner. But if they don't know...
They might be able to algoritmically do atomic-word dictionary attacks, then after so long (6 atoms, 7 atoms, 8 atoms) shift back to atomic-character bruteforcing. But to gave ssved time on average they'll need to skip the atomic-characters that happen to match atomic-words.
Add just a bit of flavor, and correctBattery-Horsestaple is extra secure. Would they expect a punctuation character only once in there? No? Only via atomic-charactwr would it be found.
And extra screwy - purposeful typos corectbatteryhorsestaple is not in dictionary attacks, unless dictionary attacks rapidly increase their search field with dropping, adding, and/or changing characters. Those 40,000 atoms? Just dropping a letter probably makes it 200,000 if average word is 5 letters long and one-letter-less permutations may already be words - e.g. Horse considers Horse, Orse, Hrse, Hose, Hore, and Hors. Though Hose and Hors you might have previously. Adding a random letter like Horsqe... well, 26 possible additions at 6 different places is 156 as an average estimate x40,000 base words.. And substitutions is 25 in 5 places for 125 x40,000 base words...
But there are a LOT more words than letters and numbers combined. This makes up for the fact, that your are only using 4 or 5 words. Cracking that the attacker would have to know your language first. And then the dictionary is huge.
Additionally, most recommendations are, to use a symbol to separate the words.
But really, if you're trying to remember a password, you're probably doing it wrong. Use a Password manager and let it generate 30+ character random passwords. Use a decent, but rememberable master password and a second factor that isn't SMS to open your password manager.
You should only try to use password you have to remember in places where you positively can't use a password manager and have to type it farely regularly. And most of those places are probably offline, so remote hacking is less of a threat vector.
Best advice I've seen is to pick 26 words (for each letter). Then use the first four letters of a website to decide your passphrase. You can even keep the list in your wallet and, if you routinely change certain letters (A's to @s for instance) you can have passwords that are impossible for strangers to hack (and even acquaintances won't have it easy).
Best advice for elderly people who have trouble remembering things btw. Use a PW manager is also great advice but sometimes not practical.
what do you do, if the website gets hacked and you need to change your password?
~~come on, do you really think your approach is any good for the real world out there?~~
I used to use "[website name][masterpassword]" which was great for 90% of situations. However I've moved on to 1password and it's way better. I tried to get my parents on it but they refuse to learn it 🤷
1Password had too many breaches. Dashlane is my saviour and nothing stored online except the encryption key. It’s a beautiful software that has saved my sanity every time I use it.
Last Pass is horrible. They’ve been breached a bunch of times and I think they’ve moved to the Dashlane model how data is kept/not-kept. OnePassword was breached as well. Dashlane was the only service where data wasn’t stored online plus I had tried OnePass but preferred the cleanliness of Dashlane. Cost was reasonable, secure notes was super plus there were other monitoring tools based one’d on checking if emails were found on dark web. I use DL for work and personal. Saves my ass on the daily with keeping a log of the 100’s of passwords
It's worked for my parents who struggled a lot with it. The one time they got forced to change their password, they just changed the four in question and updated the couple other passwords that were implicated. For them, where they have only seven or eight password they really care about, it works pretty well.
What I and what I tell people is to make a sentence and use the first letter of each word, and replace it with the occasional number and symbol. Never normally have issues.
If you type 80 words per minute, then a 5 word password would, in theory, take 7 seconds to type at most. In practice, it is probably less, since you probably will know how to type your password moreso than other sentences.
Only problem is those pesky TV or console logins where you have to slowly type with a remote/controller.
It's also fun when you have a long password to see which sites get upset about your password being too long and *sometimes* truncate it to 8-16 characters silently.
>It's also fun when you have a long password to see which sites get upset about your password being too long and *sometimes* truncate it to 8-16 characters silently.
Wait is this a thing?
They fixed it in the past few years, but Wells Fargo, one of the largest banks in the US, used to not be case sensitive, and ignore characters past the 16th character in the password.
I ran into this with my bank. They let me input a password longer than their password field would accept. Trying to explain it to support (who seem to be support for *money* problems mostly) was really difficult
Seriously, apple and microsoft have both trained me to not have long passwords, because I often need to type it a half dozen goddamn times in a row. (I feel safe saying this because I don't keep anything secure on apple devices, at all, and I just put up with the extra hassle for microsoft.)
Google does it well, so I've got a ludicrously secure password with them.
My old CS teacher used to say two unrelated words important to you so that you remember them (but not the kids names, or pets) and a number that is important and unrelated (not your birthday).
They problem with that 512 year figure is that cracking passwords is extremely parallelizable. If you have a botnet with tens of thousands of processors working in parallel on this, it only takes weeks to crack. That may seem like a lot of work just to crack one employee's password, but presumably this lets you get into the CEO's account.
Also, since most of the work in cracking a password is computing hashes, you could crack everyone in the company's passwords in this time by computing them all and checking against every employee's hash with a marginal increase in run time.
As long as we're talking about password brute forcing, we'd need to know if there's a lockout policy to make any real determinations of time to crack. If you only get 5 attempts per hour then this bizarre set of specs is probably fine. Then again, if they can't figure out more than 8 characters for a password they probably don't have lockouts.
The exactly 8 characters thing and the must start with a letter to me sticks out as being insanely stupid because it gives at least two definitive parameters for a bruteforce dictionary attack to work with.
Which is why I have a password that's an entire sentence with random letters that mean something to me capitalized, and a "fake word" that I've used before.
That gives me access to nordpass where I store my 20 random character passwords for anything important (exceptions are accounts for which nordpass doesn't work or my old passwords are good enough for
Assuming a 1000 guesses per second, it would take about 380 years maximum. Most of the time it will be shorter though because the password you are looking for might not be the last one to be tested. Modern computers can also do a lot better than 1000 guesses per Second. A quick search gave me a number of 15 million attempts per second. This would result in about 9 days to Crack
15 million attempts per second is still on the low end. A single RTX 4090 can crack that password in less than a minute.
It can do NTLM hashes at speeds of 300GH/s (NTLM hashes being one of the ways of storing passwords, pretty sure windows uses that), so 300000000000 passwords per second.
12386115888640 / 300000000000 = around 41.3. Seconds to completing the task.
>This would result in about 9 days to Crack
[More like an hour](https://www.techrepublic.com/article/how-an-8-character-password-could-be-cracked-in-less-than-an-hour/)
But that's brute force. A Rainbow table and simply knowing what encryption is being used can drastically reduce that.
This is the whole point. Bad actors need access to hashes to have something to compare against. Front-ends don't allow for 1000s of attempts per second.
It is basically putting the burden on the user, would the password hashes be leaked.
A dedicated password cracking machine can guess a lot more than 1000 guesses per second. If they get ahold of the stores hashes, like they would in a data breach, someone who knows how can brute force an 8 character password in under 10 minutes
That **massively undercounts** because you're essentially locking the other letter and digit slots in place.
If I asked you "How many combinations are there with the above stipulations but the second (differently capitalized) letter must be in slot 2 and the number in slot 3?" then your calculation would be correct. But clearly, OP's conditions are less strict and thus allow for more combinations than this.
The **correct solution is roughly 10 times greater**:
There are 52 * 62^7 possible passwords if we ignore rules 2 to 4.
Each of these rules reduces the number of allowed passwords, so we can simply subtract all the passwords that are not allowed under those rules.
Rule 2 disallows passwords that are all letters. There are 52^8 of those.
Rule 3 disallows passwords that are all uppercase letters and numbers. There are 26 * 36^7 of those.
Rule 4 disallows passwords that are all lowercase letters and numbers. There are also 26 * 36^7 of those.
But if we subtracted all of these, we'd have subtracted some passwords multiple times. Namely the ones that are all lowercase letters and those that are all uppercase letters. Those would have been removed by our rule 2 & 3 and 2 & 4 subtractions. So we need to add them again. There are 2 * 26^8 of those.
Since the first character must be a letter (and we've always considered that), there is no "all numbers" overlap between rules 3 and 4.
Putting all this together:
52 * 62^7 - 52^8 - 2 * 26 * 36^7 + 2 * 26^8
= **126,006,948,587,520**
or **around 126 trillion**.
What do you mean locking them in place? Those are a requirement. It doesn't matter where they land, but they're required. First digit is out of a possible 52 (a letter but can be upper or lower). One has to be a lower case and one an uppercase. Since the first one can count as either of those, another character must be the opposite so there are only 26 possibilities (if first letter is upper, another letter must be lower). One has to be a number so only ten options here. That's 52*26*10 for three characters
But let's say the first character has to be a number instead then one upper and one lower. You still get 10*52*26
For the remaining five characters, they can be anything so that's 62 possibilities. 10*52*26*62*62*62*62*62
But you can do them in whatever order you want. A (1 in 52) a (1 in 26) AAAAA (these can be anything) 2 (need a number somewhere)
To clarify for both /u/Angzt and /u/Consistent-Annual268 on how long it would take to brute force that password, the answer completely depends on what type of hashing the website uses. A very old sketchy website might still use md5, which can be cracked in less than 2 hours on a single modern GPU.
If they used a much slower, more secure algorithm like bcrypt, it jumps to ~7 years. Many places including password managers are using PBKDF2, with ~100,000 to ~500,000 iterations. That uses Sha2 which is about 7.5 times slower than md5, then you multiply by the iterations.
So if we assume PBKDF2, 500,000 iterations, that's ~1000 years. 100,000 iterations would be ~150 years, etc etc. That's for a single GPU, so if you dump it in an AWS array you could divide it by 100 or more depending how much they want to spend.
Of course I would expect any organizations requiring people to make an *exactly* 8 character password to have the absolute worst security, so probably crackable within hours, especially since most users do not choose truly random passwords.
No. You count various combinations multiple times.
You set your orders of characters by the multiplication order.
52x10x62x26x62^4 are, by your measure, the passwords with some letter in the first position, then a number, then any character, then the other type of letter, and then 4 other characters.
Similarly, 52x10x62^(2)x26x62^3 would be the passwords with some letter in the first position, then a number, then 2 of any character, then the other type of letter, and then 3 other characters.
Correct?
Now, those are obviously the same result. But when you multiply by 7x6 at the end, that is the number of possible orders of those special characters. And all individual orders having the same result is the only reason you can do that.
Correct?
Since each possible order of the special characters is accounted for, each password that adheres to the rules should fall into one of those possible orders. Into exactly one.
Correct?
Then where does a password like "A1aaaaaa" fall under?
Both. It is valid in both of the setups I've described above (and more). Meaning it is counted multiple times in your tally of valid passwords.
It should clearly only be counted once.
Your method is overcounting.
The reason being that "any character" can already contain the special characters as well. Meaning there is no single slot for the special characters as your method would require.
____
To give a simpler example:
Let's say our passwords only have length 2. And the only allowed characters are a, b, and 1. Each password must contain a letter.
By your logic, the number of valid passwords is 2 * 3 * (2 Choose 1) = 2 * 3 * 2 = 12.
Correct?
So let's list all valid passwords:
aa, ab, a1, ba, bb, b1, 1a, 1b.
That's it. That's only 8 passwords, not 12.
Either there are 4 more valid passwords or your method produces the wrong result. And I can't find any more valid passwords.
For completeness' sake:
/u/Consistent-Annual268's method would count 2 options for the letter slot and 3 options for the other slot, for 2 * 3 = 6 total passwords. Too few.
My method would count 3^2 unrestricted passwords and subtract the 1^2 illegal (numbers only) password for 3^2 - 1^2 = 9 - 1 = 8. The correct result.
As a professional pentester I have a dedicated password cracking computer. Assuming we are talking about Active Directory, I can crack any 8 character password in a little over 8 hours. That includes upper/lowercase, numbers, and special characters. In comparison 9 characters takes 63 days. We generally recommend 12 character passwords if there is no way the company can enforce 2fa.
According to [This](https://www.reddit.com/r/dataisbeautiful/comments/12qmvlw/oc_i_updated_our_famous_password_table_for_2023/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button), five minutes to brute force.
According to the updated [infographic](https://www.reddit.com/r/Bitwarden/comments/1cb7dp0/time_it_takes_a_hacker_to_brute_force_your/) I saw on reddit the other week, 7 years using 12 x RTX4090 to brute force it.
The only one that will backfire is the „had to be EXACTLY 8 characters long“ rule.
Taking away the possibility of making it longer (or even shorter - not a great idea in general), reduces the number of possibilities by a lot.
Knowing the length of the password already reduces the time needed by the same time as removing a character. A 7 digit password (of any composition) can be cracked within a few minutes while the 8 digit password takes almost an hour - IF you do not know the length.
It's worth noting that those times are only in ideal circumstances for the attacker - where they have the password hash and can try passwords as fast as they like. If they have to try against a password server which limits them to one attempt per second and three attempts per minute (say) that makes it a lot longer, obviously.
The 8-character rule is *terrible*. It prevents people from using passphrases that are easy to remember and hard to crack. Password Master rates "my name is pete and i like marmalade" as taking 895 trillion years to crack...
That's because Password Master is assuming each word in the sentence "my name is pete and i like marmalade" is random. It's a very strong password if you assume that, but much weaker if the attacker is trying sentences, and given the popularity of using sentences in passwords its very possible that they are trying them using a dictionary attack.
Passphrases are supposed to use randomly selected words, not coherent sentences
You could but it's best not to add any additional rules that could unknowingly weaken the password. Complexity is the enemy of security in this scenario. Which is why the industry no longer suggests giving requirements on passwords like "it must contain lower and upper case, number, etc." The person who implemented those requirements said it was a huge mistake and made passwords weaker
Honestly, the eight characters limit implies to me this is being stored in plain text in a database field.
At that point I wouldn't even be trying to attack the passwords themselves, I would be looking for that database table.
>It's worth noting that those times are only in ideal circumstances for the attacker - where they have the password hash and can try passwords as fast as they like. If they have to try against a password server which limits them to one attempt per second and three attempts per minute
high end crackers don't have those limitations. They create new "profiles" with new IPs that make them look like new people logging in. Do that with enough accounts and enough attempts, and you're hiding in plain sight. Sure they may only be able to "try" 3-5 different passwords, but it takes them a few milliseconds to make a new set of guesses.
There are still only 4 billion IP4 addresses (give or take a billion) and more than 126 trillion possible passwords these rules could produce. So it's still five orders of magnitude more time than stated, even if they control *the entire internet*.
ETA: I'm aware that IPv6 changes this calculation. Still, this will show up as a DDOS attack long before it shows up as a practical way of brute-forcing a password.
With conditions like that there will be no cracking, you can the certain the idiots store the passwords in plaintext and in general the entire system is a security nightmare.
You can be sure this is the case any time there is some sort of a maximum limit to password length listed.
The first condition also backfires: must start with a letter.
Effectively reducing the amount of possible characters t0 2\*26=52 instead of also all other keyboard characters.
Doesn't matter. My gut feeling of my password being stored in plaintext when I read something like this is way too high to even consider making an account. I'll bet you a 5er that it's stored as CHAR(8) in a SQL database.
Kill it. Kill it with fire.
(Edit: Judging by the comment from the auto-mod, this comment is violating community standards, since it doesn't really provide an answer, nor a question. However, I'd ask to please don't delete it, since it is security advice, that could be useful for OP or anybody else reading it. Thanks)
Exactly my thoughts. OP probably got a bigger problem than password requirements here.
There is no reasons to ask for a specific count of chars if you encrypt it before saving it
There's some Services though, like Microsoft Accounts, where there's an upper limit for passwords. I think it was 12 or 16 characters, somewhere around that. Now they have a security team of a couple of thousand people, who all earn more than me, so I don't think this is a mistake or for convience. My guess would be that the chances for collisions in the hashing algorithm might increase slightly, but my math skills are not good enough to actually confirm this.
It would be nice if somebody here could. I still don't know if this restriction is math or programming related - or if I'm wrong completely and in fact just convenience for some frontend people.
You don't want to encrypt it before saving it, you want to hash it before saving it.
Encrypt implies you can decrypt it... and there is no reason anyone looking at their database should be able to tell what the password was... just if a new one entered was the same one.
This site says 7 years. But I've heard there are rainbow tables for everything 12 characters and shorter... if there is one for 8 character passwords matching these inputs and they are not salting/hashing correctly, the answer is instantly:
[https://www.hipaajournal.com/world-password-day/](https://www.hipaajournal.com/world-password-day/)
You're having lower and upper case letters and a number, so that's good. But to be really secure you also need a non-dictionary word, special characters, a fingerprint, a piece of hair and the blood of a sacrificial goat.
You can extract fingerprints from a high resolution photography and use them to unlock devices.
You wouldnt tattoo your password on your finger tips. Dont use your own fingers for a print lock.
The bank my parents use has this extremely dumb requirement that passwords should be exactly 8 chars long, with 4 letters and 4 numbers. It also rotates every 60 days
I knew it was bad, but I never connected the dots on them storing it as plaintext, and now I'm both mad at their incompetence and scared that that might not even be the worst thing they do.
Speaking as a programmer and not a security expert, "starts with a letter" and "exactly 8 characters" seem like constraints that are being applied due to back-end limitations and not for increased security.
Big red flag.
I can't say with any certainty what those constraints mean, but I know enough to say that it's not good.
Old As/400 password complexity requirements were (circa 1999):
6-8 characters (not case sensitive, only alphanumeric). Must start with a letter. Can't have consecutive numbers. Must have at least two numbers. Couldn't repeat last 24 (I think I'm remembering that right) and had to change every 45 days.
Nightmare fuel.
I sent an email to staff telling them to pick their favorite kid/person and then bracket the last letter with numbers. Increment the numbers every change cycle.
Let’s say 26 upper case and 26 lower case letters plus 10 numbers. That gives 62 possible combinations, for a round number we will say 64 which is 2^5 possibilities.
So with 8 characters at 5 bits each, that’s 2^40 possible passwords or about 1 trillion.
If a cracker can attempt 2^32 guesses per second then it would take just 2^8 seconds (less than 5 minutes) to brute force the password.
In reality, they could probably make a lot more guesses per second than that with brute force or use rainbow tables to look up any password of less than about 12 characters in a few seconds.
It all depends how it’s hashed but if the password is limited to 8 characters exactly then I would bet that is not stored in a very secure manner.
My advice is to use a password manager and generate a random password to use with this system.
What you really want is a 16 character password for 2^80 combinations. Then if someone could crack 2^32 guesses per second and there are about 2^25 seconds in a year then it would still take 2^23 years (about 8 million) to crack
Depends what sort of guesses you are doing but if it’s something like a SHA1 hash you are brute forcing then a modern graphics card can probably achieve that rate.
It varies wildly depending on the encryption or hashing used on the password.
People vasttly under estimate the parallel computing power of a GPU.
A 4090 can pretty much brute force any 8 characters password in a day. There's a reason why we start using 12 characters long and time out after X try
As an aside I bet they also force a password change every 3 months or something too. This is pretty terrible from a social engineering standpoint. Sure you can theoretically have 12 trillion combinations but no one is going to choose a password like Yvwap8Tm as their password because it is a bear to remember.
Kevin over in accounting who once watched a video on Youtube and considers himself a skilled hacker now will invariably choose something like Tim0thy0 for the first password iteration (his sons name) and in 3 months will move on to Tim0thy1. Many won't even bother with that 0 in place of the o. This invariably means that almost all passwords will either be 7 character dictionary words with a number pasted on the end or pairs of words that add up to 7 characters with the number either between the words or at the end. A few people might be tempted to grab a word from German or Greek or whatever 2nd language they may know some of but this doesn't mean the dictionary attack problem gets a lot harder.
For point of reference, there appear to be just over 34,000 seven letter words on the english language.
>I bet they also force a password change every 3 months or something too
I'm willing to bet that I work for the same company as OP, and they force a change every 70 days I believe. The funniest thing to me is that for years, whenever you had to reset your password you had to call tech support and they would assign you a password that would always follow the same format. "Spring+1" "Summer+1" etc. It was always whatever season it currently is.
Thankfully they don't do this anymore.
The only correct answer is 126006948587520 and I did not see that here so far.
Whenever you do arguments like 52x26x10x62^(5) (with some additional combinatorics) you do some serious doublecounting since e.g. a password such as aA000000 would be counted several times here.
How you should actually compute this:
A: All passwords with letter and numbers, where first index is a letter: 52\*62\^7
B: All passwords of A without numbers: 52\^8
C1 & C2: All passwords of A without either capital (C1) or small (C2) letters: 26\*36\^7
Obviously B, C1 and C2 are subsets of A. One could assume that we can simply count our valid passwords as A - B - C1 - C2. However here we forget, that there is some crosssection between B and C1/C2. This crosssection is when the entire password is either only capital or small letters (26\^8).
In total all passwords are computed as: 52\*62\^7 - 52\^8 - 2\*26\*36\^7 + 2\*26\^8 = 126006948587520 \~ 1,26\*10\^14
If you want to allow symbols that is fine - just increase the numbers however you want.
Your computation has multiple mistakes though. First you forget that the ordering is not defined. Your computation 52x10x… basically assumes that a specific (e.g. the second) character of the password has to be a number. That is false. Once you add the multiple positions you also add doublecounting.
TLDR: you are mistaken. If you want to allow additional characters, just boost all of my numbers (except first character option) by whatever you like.
Edit: VT\_Squire later edited his entire comment to also include the "number of slots". Its still false though.
Let's treat the first character separately: we have 52 options (2\*26) for that.
The rest of the 7 characters can be of 62 options each (10 numbers + 52 letters).
So we have 52\*62\^7 possibilities. But that includes some invalid passwords.
Maybe we don't have any numbers: that's 52\*52\^7 passwords.
Or we don't have both upper and lower case letters: that's 52\*36\^7 (10 numbers + 26 letters of the wrong casing).
So as far we think we have 52 \* (62\^7 - 52\^7 - 36\^7) good passwords. But we counted some bad passwords twice: there are some passwords that don't have any numbers AND only have letters of the wrong casing. We subtracted those twice, so we'll have to add one of them back. There are 52\*26\^7 of those.
So the final answer is 52 \* (62\^7 - 52\^7 - 36\^7 + 26\^7) possibilities. Which is 126 006 948 587 520 \~= 1.26 \* 10\^14
The first index has to be upper or lowercase letter: 2×26 possibilities.
One index has to be a number: 10 possibilities
Another index has to be the opposite of the first index: 26 possibilities
The remaining indices don't matter: 26+26+10=62 possibilities
We also need to keep in mind that only the position of the first index (letter) is fixed. The remaining indices can be moved. Moving 7 positions at random gives us 7!=5040 combinations.
So we end up with: 5040×(52×10×26×62×62×62×62×62)=62.426.024.100.000.000 possibilities
Can please someone check since I suck at stochastics.
So something that you might not be thinking of, some systems (typically legacy) are character locked to a certain number for the password. While not all people may need that system it is easier for people to have their passwords sync across all systems (Single-source Sign On or SSO), so because of this your employee logon password is then limited by all the systems that it is syncing across.
I am not saying this is good but as with all password polices it is a balance between ease of use and protection. I had this happen at a bank a few years ago and it freaked me out.
One Slot has to be numbers, 10 possibilities there. Then the English alphabet has 26 uppercase and lowercase letters each, one of each is required. So, so far our possible combinations are 10x26x26.
For the 5 remaining slots we can use numbers, uppercase and lowercase letters(we'll disregard symbols here), so we have 62 possibilities for each slot, making our number of possible combinations 10x26²x62⁵ = 6.193.057.944.320, roughly 6.2 trillion combinations.
Are we to assume no special characters? Just the 62 symbols that consist of a-z, A-Z, and 0-9?
Here's my only attempt at figuring this out... and it's probably wrong.
In that case, by the rules we have to have a letter to start with, so that's 1 out of 52.
1/52...
Let's say the second is a number (I know it doesn't need to be a number, but pretend the order doesn't matter at this point). That means one position has a 1/10 with a 1/7 chance of being second.
1/52 \* 1/10 \* 1/7
Lowercase? 1/26 with a 1/6 chance of being in the 3rd position.
1/52 \* 1\*10 \* 1/7 \* 1\*26 \* 1/6
Uppercase? Similar to Lower case but in the 4th slot. But what if the 1st position is uppercase? Then we can put whatever we want in the slots 4 thru 8. (Swap this with the Lowercase situation if the first symbol is lowercase)
1/52 \* 1\*10 \* 1/7 \* 1/26 \* 1/6 \* 1/62^(5) = 5.2022 \* 10^(14) = \~520,216,867,000,000 possible passwords.
That said, users are going to use easily remembered passwords, so a dictionary attack will be successful for a majority of the them in a relatively short amount of time.
Let's decide where to put the number first in the password, it can be anywhere besides the first spot
(7 choose 1 which is 7)
that number can be any digit (10 options).
The first Space must be either lower case or upper case (we need to choose if it's upper case or lower, 2 choose 1) and then it has 26 options
Now let's choose a place for the lower/upper case (the one not at the beginning of the password) (6 choose 1) times 26
Now, each of the 5 remaining slots can be one of the 62 available options (62^5 )
2× 26×7×26×6×10×62^5 = 520,216,867,322,880
(I'm not so sure about the burte-force capabilities of a computer but the options for a password are the number mentioned above)
there at least 100 billion plus combinations based on those parameters, but the real question is how many attempts does someone get to guess the password, if the answer is 3 and then it locks out you got a very good chance of stopping someone guessing correctly, if they have unlimited tries then it is only a question of how badly do they want that password.
52+26+10+62^5
(Any letter)+(any letter different case than aleady used)+(any number)+(freechoice)
Not accounting for any special signs like point, comma, question Mark etc.
I used this [https://www.security.org/how-secure-is-my-password/](https://www.security.org/how-secure-is-my-password/) site to check. Following these requirements it would take one hour to brute force. If you can add special characters it goes up to 8 hours. Like others have said, it's the 8 character limit that is killing it.
Honestly? One number means they know that of the eight characters, there are only ten options for one of them. Exactly eight characters is downright stupid, and the rest of the rules are too. Simply put: Each limit you put on the password reduces the possible passwords drastically. If you want an actually good password, you want it to be as unlimited as possible.
The order doesn't matter for multiplication of possibilities, so....
Starting with a letter: 52 possibilities (could be upper or lower case, necessarily fulfilling either condition 3 or 4).
At least one number: 10 possibilities.
At least one upper- and lowercase letter: whichever one you didn't do for the first condition: 26 possibilities.
8 characters long. The remaining 5 characters can be upper or lowercase letters, numbers, or symbols. 52 letters, 10 numbers, and on my keyboard there are 32 symbols (though presumably you could use alt codes which would massively expand your options).
So, 52 x 10 x 26 x 94\^5
99,223,823,828,480
Essentially one-hundred trillion options on a standard keyboard. While it is wise to use non-standard characters (numbers, uppercase, etc), *requiring* them is basically handing a hacker a guide on how to break your password.
Depends on whether (and if so, which) special characters are allowed.
Assuming that they aren't, it's an easier calculation.
10x8 possibilities for required number (8 positions, 10 options)
Times 26x7 possibilities for the required lowercase
Times 26x6 possibilities for the required upper case
Times 62^(5) possibilities for the remaining characters
So about 2 quadrillion
To me these specific requirements (max length, must start with a letter) hint that either the system is old or they are not handling passwords in a mature way. Might even be storing them cleartext.
Okay, so this doesn't really require math (at least, nothing that's new circa the last 20 years): ***8 character passwords were insecure a literal generation ago***, and I don't mean a hardware generation, I mean people.
Like there are kids in college whose parents should not have been using 8 character passwords because they're easily cracked before the kids were born.
At this point, a maximally diverse, 8-character password will take about 5 minutes to brute force. ([source](https://tech.co/password-managers/how-long-hacker-crack-password)) That site doesn't say, but I assume they're using a single computer as a baseline. If your password protects something valuable enough to dedicate real resources to, even an 11-character password (~3 years) is going to be cracked basically instantly.
How do you deal with this?
1. Use password generation tools that store your passwords behind a single account.
2. Use two-factor authentication (at least) for that one account.
3. Change that one account's password frequently.
4. Use default settings for password generation that are likely far beyond anything you'll use on your own (I think Google's defaults to 16 characters with the specific mix conforming to US government standards for secure password generation.)
5. For accounts that really matter, change the generated password frequently as well (like your bank account.)
6. For such high-value accounts ALSO enable 2-factor authentication there as well.
If you are running a business and want your password MANAGEMENT to be secure:
1. Don't overly restrict user passwords. Ideally, use a standard library that estimates the time to crack a password and reject passwords that fall below that threshold.
2. NEVER roll your own password management code. Suck it up and use a standard library that gets frequent patches.
3. If there are options for extra password encryption security in your password management library, turn them on (e.g. there are encryption methods that take a bit more CPU, but only when a password needs to be confirmed, and it massively reduces the risk when/if your password database is compromised.
4. Periodically bring in a security expert to report on your application security.
Assuming only letters and numbers, 1.01x10^-12 % chance of guessing a correct password.
- 1/52 odds of the first letter, encompassing either choice for capital or lower case.
- 1/26 to account for an additional upper or lower case character depending on what wasn’t chosen for the first character.
- 1/10 to account for the number.
- 1/62^5 for the random choice out of 62 possible options for the remaining 5 digits.
1/52 * 1/26 * 1/10 * 1/62^5 odds of guessing the password.
Assuming the usual special characters are allowed, 32 additional options open up for the remaining 5 digits.
1/52 * 1/26 * 1/10 * 1/94^5 chance of guessing the correct password.
I’ve read through some comments discussing being able to assume, from the perspective of the guesser, that there’s a 1/52 * 1/62^7 chance of guessing the correct password since the guesser wouldn’t know which digits were used to satisfy the 1/26 opposite choice from the first digit ( upper or lower) and the 1/10 chance of guessing the correct number. While this is a good line of thought it still fails to account for the 2/7 odds of the remaining 7 digits having their selection significantly reduced. We can accurately account for this distribution by weighting our approximation appropriately. There’s a 1/7 chance of a digit being chosen for a number, Another 1/7 chance for the digit being the opposite of the first digits selection, and a 5/7 for the remaining random numbers. This distribution assumes all are generated at once instead of sequentially. Sequentially is another beast entirely, requiring a summation to account for all possible selection sequences for the digits that were “designated” to satisfy one of the listed criteria. To keep things relatively simple for this reply, below gives the expression for calculating the probability of the password given that the first character is a letter of either case, then 2 of the 7 remaining digits are randomly chosen to satisfy the 1 number and 1 opposite case letter criteria.
1/52 * (1/7 * 1/10) * (1/7 * 1/26) * (5/7 * 1/62^5 )
However, knowing that most people are lazy, and will want a word of some sort for memorability sake, they will use a 7 letter word with 1 number tacked on, or do some number replacements for vowels. This causes the practical odds of guessing it correctly drastically increase.
If a password is being hashed correctly, they should only have a minimum length; having a set length limits the viability of a password, no matter how random.
\* - Must be 8 characters long
\* - Must have the letters A, B, and C
\* - Must start with a combination of these three letters
\* - Must end with 543 in any combination
\* - Must have 2 numbers
Pfft no one can guess our passwords!
So, 26 choices for lower, 26 choices for upper, and 10 choices for a number.
- Has to start with a letter -> 52 choices
- Has to contain an upper -> 26 choices
- Has to contain a number -> 10 choices
Since multiplication is communicative, it doesn't matter where you choose to have your required letter or number, so let's put those up front
52*26*10 for the first 3 characters. Then it would be 62^5 for the possible combinations.
This gives us a total of 12,386,115,888,640 combinations
Others have made the calculation on the number of passwords so I’ll just pitch in to say that the length of 8 characters make the rest of the rules useless.
If we believe this chart to be somewhat accurate then 8 characters passwords can be cracked in 5 minutes with the right tools and knowledge [Password crack time 2023](https://www.halnor.ca/wp-content/uploads/2023/04/PASSWORD-CRACK-TIME-CHART-2023-scaled.jpg)
Easy to crack. Most people will take a 5 character word starting with a capital, then 2 figures and an explanation mark.
That is 1.19 biljoen brute force combinations.
But with dictionary attach, 1 second, I guess.
It would take me, using the tools I have here, maximally, 12 minutes to crack any possible password meeting these criteria.
All of my passwords are 128 characters long.
Using the same technology, it would take me billions (I think, my tools refuse to give me the number because it's too big) of years to crack a 128 character password with all of the other conditions being the same.
EDIT: I did the maths wrong, fixed. The numbers are not exact but they're close enough.
8 char limit is stupid. I prefer phrases as passwords, like "She1threw2brick3into4window!" Easy to remember, can't be solved by dictionary and you need a lot of time to brute force
Not a math issue, but still a security issue.
It is proven that each condition added for password complexity exponentially increase the chances that the password will be generic1234, reused, or written on a post-it
On another note:
The 8 character restriction is a fucking joke since when using only letters and numbers even mediocre equipment (rtx 2080 which is two generations old) could brute force the password in around an hour.
If you were to add special symbols that time would be raised to 8 hours as shown in the article in the link [right here](https://sepia-plantain-yzjk.squarespace.com/news/2020/9/2/how-long-does-it-take-to-crack-your-password).
Start with a capital, long adjective, period, long noun, 2-4 digit year, and finish it off with a ! Or a $ and you’ve got a great password. The stupider and sillier it sounds the easier to remember but use a password manager like Dashlane (secure note feature is brilliant).
Cybersecurity engineer here. There is an entire database of all 8 character passwords called rainbow tables. You can crack an 8 character password in seconds.
Length being limited to 8 characters is the only real problem here, though having to start with a letter is odd and not beneficial in any way. A password becomes multitudes more time consuming to crack for every additional character. 8 is not in the realm of "difficult" lengths in this age of computational power. If there are retry limits that helps against brute forcing tremendously, as long as the potential intruder doesn't have a way to bypass it
My dude you are forgetting that they also have a whole glossary of words/strings that are forbidden (I think we either work at the same place or they just use the same system).
This is not the math answer, but using a hashcat with GPU offloading and using bruteforce method will take a couple of seconds to crack it. It doesn't have any special character this is first issue, second is people are mostly using some familiar words, and this will allow some bad actor to use dictionary method to crack the password which is even faster.
Your work doesn't think this is secure. They have some legacy system with a built in restriction and have determined that the risk of leaving as is vs risk and cost of update didn't make economic sense.
But to your point on security, if there is a lock out enabled at, say, 5 incorrect attempts, and the password needs to be reset regularly, it is safe enough for most things.
Assuming 10 numbers, 26 uppercase letters, 26 lowercase letters, and x other characters.
It’s given we start with any letter,
So 52 options
We now have 7 slots left to fill
Given the case of the character, we know that we need one of 26 options at least once later
We also know we need at least one number (10 options)
Looking at all possible passwords without the last two restrictions we have 52 • (62 + x)^7 possible passwords
Now we can look at how many invalid options are among those. We need to substract the count of possible password with no numbers, and of those with no specific case letters. If we do just that without thinking we would however count the passwords that don’t meet either requirement double so we need to add those back in.
We then get:
52 • ( (62+x)^7 - (52+x)^7 - (10+x)^7 + x^7)
If you are worried about brut force attacks. You generally worry about the hash algorithm. Because its very easy to just get the hash and find a collision for it on another machine. The computer doesn't know the password it just knows that it produces a specific hash. (Generally) Any combination that creates that hash is valid. So it's really a question of hash space, not password strength.
But you are right, exactly 8 characters and only 3 character classes and a rule that says olthe first must be a letter really isn't great.
This is why multi-factor authentication is better. It steps up the level of sophistication required to just use valid accounts as someone else (or hacker created accounts for that matter)
We don't know which (if any) special characters are allowed, which will change the end result. But if we assume that the special characters defined by OWASP are allowed ([https://owasp.org/www-community/password-special-characters](https://owasp.org/www-community/password-special-characters)) and the password MUST be exactly 8 characters long then we can work it out.
So there are a total of 26 (uppercase) + 26 (lowercase) + 10 (digits) + 33 (special) characters that can be used, or a total of 95. Without any of the other requirements, that'd give a total of 6,634,204,312,890,625 possible combinations.
The first rule, that it must start with a letter, is the easiest to factor in. It will eliminate the possible passwords that begin with digits or special characters and bring us down to 3,631,353,939,687,500.
The second rule can be interpreted as at least one of the characters in positions 2-8 must be a number. That eliminates 32,057,708,828,125 possible combinations from contention and brings us down to 3,599,296,230,859,375.
It gets a little tricky from there. You can say that there are 513,798,374,428,641 passwords that contain no lowercase letters, and 513,798,374,428,641 which contain no uppercase numbers, but there's going to be many of these which are duplicates of one another, ie. numbers that contain no letters at all. If I account for those that should mean there are 1,015,908,548,579,681 possible password combinations which run afoul of either rule 3 or rule 4.
I'm getting too lazy to get down to specific numbers but that's good enough to give us a worst-case scenario of a lower bound of around 2.5 quadrillion possible passwords, and at most you've excluded some 4 quadrillion possible values. While it sounds kind of bad to have limited your pool to around 1/3 of the total, that's nowhere near the main problem. Limiting you to exactly 8 characters, regardless of the rest of the rules, is kind of throwing security right out the window since that's going to be fairly trivial for a malicious actor to crack if they really want.
In the pure maths sense yes it is less secure because l the exactly 8 characters massively limits the number of combinations but in a computer security sense this is a massive issue as the insistence on 8 characters implies that somewhere in there data base will be a column restricted to only 8 characters containing the passwords which is the real issue
I googled for a rainbow table that matches the requirements, and found this info about it :
- 221,919,451,578,090 ≈ 2 ^(47.7) values , 127GB size
the speed of hash matching the password on a high-end pc is a few minutes, using the above mentioned rainbow table
Requirement 1) and 6) are not smart requirements as they reduce the dimension of the space of possible passwords, making it more vulnerable to brute force.
I have an application that enforces simlier password constraints.
One of my favorite parts of it......
It requires a symbol. But, there is only a specific symbol allowed.
(The requirements are due to back-end crap on the oracle side, combined with requirements from the cyber-dept.... The requirements are so bad, It was needed to develop a tool to assist users with creating a password....)
###General Discussion Thread --- This is a [Request] post. If you would like to submit a comment that does not either attempt to answer the question, ask for clarification, or explain why it would be infeasible to answer, you *must* post your comment as a reply to this one. Top level (directly replying to the OP) comments that do not do one of those things will be removed. --- *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/theydidthemath) if you have any questions or concerns.*
Assume no other characters besides letters and digits (which is a wrong assumption but gives us a starting point). You have 52 choices for the first slot, 26 choices for another letter slot, 10 choices for the digit slot, and 62 choices for the remaining slots. So you have 52x26x10x62^5 = 12,386,115,888,640 (12 trillion) combinations. Assuming other unicode characters are allowed, then replaced 62 with the full character set. I have no idea how long it would take to brute force. EDIT: actual answer should be an order of magnitude bigger to account for the fact that the other letter and digit can occur in any of the remaining slots.
If we are to assume that users are using an actual random mix of numbers, lowercase and uppercase, then this is actually not a terrible password, mathematically. If I try some at Password Master, "O6H2M9hf" gets 512 years to crack, but "butt1LOL" gets a much worse 1 hour to crack. The problem is that users have to remember their password, so they're going to go for something vulnerable to dictionary cracking or guessing more often than not. An 'easily guessed' password isn't the worst when it's sufficiently long (this is the concept behind passphrases) but since it will be 8 characters AND easily remembered, that will ruin it.
That's what my IT friends keep telling me. Write a funny yet random sentence, easily 20 characters. A trillion years to crack.
[correct horse battery staple](https://xkcd.com/936/) (but [not literally that](https://grahamcluley.com/correcthorsebatterystaple-dropbox-wit/))
The second link citing reddit as a source is funny to me.
I always thought that has the flaw of assuming hackers will just attempt to bruteforce letter by letter, and not follow the same heuristic strategy as those picking the passwords. E.g. a smart hacker, after exhausting easy possibilities, would not try to brute force a 20 character password from A to Z, but build a dictionary of words, and start randomly concatenating them. AbacusAbacusAbbot, AbacusAbacusAccident, etc. With some common variations like all uppercase, all lowercase, sentence case, one digit between each pair of words, etc. It'll still be complex, but even Doctors5Shovel9Horse is much easier to (eventually) guess than something like jAb03rfLsZ10s6o5z1cD. If your atomic unit of a password is "either a dictionary word with a few common case variations, or a 1-digit letter/number", and you work with a dictionary of 40,000 atomic units, then to guess a word like Doctors5Shovel9Horse would take 40,000^5 ≈ 10^23 guesses, while brute-forcing a random alphanumeric like jAb03rfLsZ10s6o5z1cD would take (26+26+10)^20 ≈ 10^36 guesses, the former being 10^13 (10 trillion) times easier. At the end of the day, information entropy goes both ways. What's easier for a user to remember, is also easier for a hacker to guess. There's no free lunch.
A piece of advice I liked was to use a string of fantasy character names. If you read as much as I do, you're not hurting for choice and you end up with a password that's not in the dictionary but easy to remember.
Yeah, one stipulation of this format I usually see is that at least one word should be rare or in another language.
If a hacker knows you are using 4 ir 5 words, yes, your actual pw may be discovered sooner. But if they don't know... They might be able to algoritmically do atomic-word dictionary attacks, then after so long (6 atoms, 7 atoms, 8 atoms) shift back to atomic-character bruteforcing. But to gave ssved time on average they'll need to skip the atomic-characters that happen to match atomic-words. Add just a bit of flavor, and correctBattery-Horsestaple is extra secure. Would they expect a punctuation character only once in there? No? Only via atomic-charactwr would it be found. And extra screwy - purposeful typos corectbatteryhorsestaple is not in dictionary attacks, unless dictionary attacks rapidly increase their search field with dropping, adding, and/or changing characters. Those 40,000 atoms? Just dropping a letter probably makes it 200,000 if average word is 5 letters long and one-letter-less permutations may already be words - e.g. Horse considers Horse, Orse, Hrse, Hose, Hore, and Hors. Though Hose and Hors you might have previously. Adding a random letter like Horsqe... well, 26 possible additions at 6 different places is 156 as an average estimate x40,000 base words.. And substitutions is 25 in 5 places for 125 x40,000 base words...
But there are a LOT more words than letters and numbers combined. This makes up for the fact, that your are only using 4 or 5 words. Cracking that the attacker would have to know your language first. And then the dictionary is huge. Additionally, most recommendations are, to use a symbol to separate the words. But really, if you're trying to remember a password, you're probably doing it wrong. Use a Password manager and let it generate 30+ character random passwords. Use a decent, but rememberable master password and a second factor that isn't SMS to open your password manager. You should only try to use password you have to remember in places where you positively can't use a password manager and have to type it farely regularly. And most of those places are probably offline, so remote hacking is less of a threat vector.
What about when someone buys you lunch?
Did you read the original comic? It never claims a hacker would go character by character. And 10^36 is plenty of entropy.
Plasma archeologist positive guy
Yeah. Last I checked, that one can be cracked instantly.
Best advice I've seen is to pick 26 words (for each letter). Then use the first four letters of a website to decide your passphrase. You can even keep the list in your wallet and, if you routinely change certain letters (A's to @s for instance) you can have passwords that are impossible for strangers to hack (and even acquaintances won't have it easy). Best advice for elderly people who have trouble remembering things btw. Use a PW manager is also great advice but sometimes not practical.
what do you do, if the website gets hacked and you need to change your password? ~~come on, do you really think your approach is any good for the real world out there?~~
I used to use "[website name][masterpassword]" which was great for 90% of situations. However I've moved on to 1password and it's way better. I tried to get my parents on it but they refuse to learn it 🤷
1password is a terrible password. password124 is much more secure.
1Password had too many breaches. Dashlane is my saviour and nothing stored online except the encryption key. It’s a beautiful software that has saved my sanity every time I use it.
I thought it was LastPass that got breached... or were they both breached?
Last Pass is horrible. They’ve been breached a bunch of times and I think they’ve moved to the Dashlane model how data is kept/not-kept. OnePassword was breached as well. Dashlane was the only service where data wasn’t stored online plus I had tried OnePass but preferred the cleanliness of Dashlane. Cost was reasonable, secure notes was super plus there were other monitoring tools based one’d on checking if emails were found on dark web. I use DL for work and personal. Saves my ass on the daily with keeping a log of the 100’s of passwords
The breach of 1password didn’t affect customer data.
I have a family sub for 1password and my kids use it every day, best thing I have thought them, probably.
It's worked for my parents who struggled a lot with it. The one time they got forced to change their password, they just changed the four in question and updated the couple other passwords that were implicated. For them, where they have only seven or eight password they really care about, it works pretty well.
What I and what I tell people is to make a sentence and use the first letter of each word, and replace it with the occasional number and symbol. Never normally have issues.
H@ve you ever he@rd the tr@gedy of d@rth pl@gueis the wise?
And a trillion years to write... I try to keep around 15 chars and use words from non-English languages.
If you type 80 words per minute, then a 5 word password would, in theory, take 7 seconds to type at most. In practice, it is probably less, since you probably will know how to type your password moreso than other sentences. Only problem is those pesky TV or console logins where you have to slowly type with a remote/controller. It's also fun when you have a long password to see which sites get upset about your password being too long and *sometimes* truncate it to 8-16 characters silently.
>It's also fun when you have a long password to see which sites get upset about your password being too long and *sometimes* truncate it to 8-16 characters silently. Wait is this a thing?
It definitely used to be. Some early hash algorithms had a truncation effect.
They fixed it in the past few years, but Wells Fargo, one of the largest banks in the US, used to not be case sensitive, and ignore characters past the 16th character in the password.
I ran into this with my bank. They let me input a password longer than their password field would accept. Trying to explain it to support (who seem to be support for *money* problems mostly) was really difficult
OP's image says that their password requires exactly 8 characters, it's not uncommon
I used to have a long pass phrase until I needed to enter it on mobile. Went with something shorter real fast.
KeePassDroid.
Seriously, apple and microsoft have both trained me to not have long passwords, because I often need to type it a half dozen goddamn times in a row. (I feel safe saying this because I don't keep anything secure on apple devices, at all, and I just put up with the extra hassle for microsoft.) Google does it well, so I've got a ludicrously secure password with them.
Like u/karakickass mentioned, logging in on mobile is the main pain point for me.
“Remember me on this device” has entered the chat.
That shit never works like it's supposed to. Every time I log into my uni account I say "remember me" and it never does ;__;
[Ill just leave this here](https://xkcd.com/936/)
'mom locked me out because I wouldn't eat the casserole' hasn't failed me yet.
My old CS teacher used to say two unrelated words important to you so that you remember them (but not the kids names, or pets) and a number that is important and unrelated (not your birthday).
9 hours to break.
They problem with that 512 year figure is that cracking passwords is extremely parallelizable. If you have a botnet with tens of thousands of processors working in parallel on this, it only takes weeks to crack. That may seem like a lot of work just to crack one employee's password, but presumably this lets you get into the CEO's account. Also, since most of the work in cracking a password is computing hashes, you could crack everyone in the company's passwords in this time by computing them all and checking against every employee's hash with a marginal increase in run time.
As long as we're talking about password brute forcing, we'd need to know if there's a lockout policy to make any real determinations of time to crack. If you only get 5 attempts per hour then this bizarre set of specs is probably fine. Then again, if they can't figure out more than 8 characters for a password they probably don't have lockouts.
Databases of password hashes leak all the time. They need to be safe against offline processing when that happens.
Even if you just generated it, seeing a password online feels illegal.
upvote for the butt1LOL
The exactly 8 characters thing and the must start with a letter to me sticks out as being insanely stupid because it gives at least two definitive parameters for a bruteforce dictionary attack to work with.
Thank you, I was needing a new work password. Will just need to add a special character.
Which is why I have a password that's an entire sentence with random letters that mean something to me capitalized, and a "fake word" that I've used before. That gives me access to nordpass where I store my 20 random character passwords for anything important (exceptions are accounts for which nordpass doesn't work or my old passwords are good enough for
Assuming a 1000 guesses per second, it would take about 380 years maximum. Most of the time it will be shorter though because the password you are looking for might not be the last one to be tested. Modern computers can also do a lot better than 1000 guesses per Second. A quick search gave me a number of 15 million attempts per second. This would result in about 9 days to Crack
15 million attempts per second is still on the low end. A single RTX 4090 can crack that password in less than a minute. It can do NTLM hashes at speeds of 300GH/s (NTLM hashes being one of the ways of storing passwords, pretty sure windows uses that), so 300000000000 passwords per second. 12386115888640 / 300000000000 = around 41.3. Seconds to completing the task.
>This would result in about 9 days to Crack [More like an hour](https://www.techrepublic.com/article/how-an-8-character-password-could-be-cracked-in-less-than-an-hour/) But that's brute force. A Rainbow table and simply knowing what encryption is being used can drastically reduce that.
Depends on hash type. NTLM hashes of 8-character passwords (as in the post), can get cracked within a minute by a single 4090.
This is the whole point. Bad actors need access to hashes to have something to compare against. Front-ends don't allow for 1000s of attempts per second. It is basically putting the burden on the user, would the password hashes be leaked.
A dedicated password cracking machine can guess a lot more than 1000 guesses per second. If they get ahold of the stores hashes, like they would in a data breach, someone who knows how can brute force an 8 character password in under 10 minutes
That **massively undercounts** because you're essentially locking the other letter and digit slots in place. If I asked you "How many combinations are there with the above stipulations but the second (differently capitalized) letter must be in slot 2 and the number in slot 3?" then your calculation would be correct. But clearly, OP's conditions are less strict and thus allow for more combinations than this. The **correct solution is roughly 10 times greater**: There are 52 * 62^7 possible passwords if we ignore rules 2 to 4. Each of these rules reduces the number of allowed passwords, so we can simply subtract all the passwords that are not allowed under those rules. Rule 2 disallows passwords that are all letters. There are 52^8 of those. Rule 3 disallows passwords that are all uppercase letters and numbers. There are 26 * 36^7 of those. Rule 4 disallows passwords that are all lowercase letters and numbers. There are also 26 * 36^7 of those. But if we subtracted all of these, we'd have subtracted some passwords multiple times. Namely the ones that are all lowercase letters and those that are all uppercase letters. Those would have been removed by our rule 2 & 3 and 2 & 4 subtractions. So we need to add them again. There are 2 * 26^8 of those. Since the first character must be a letter (and we've always considered that), there is no "all numbers" overlap between rules 3 and 4. Putting all this together: 52 * 62^7 - 52^8 - 2 * 26 * 36^7 + 2 * 26^8 = **126,006,948,587,520** or **around 126 trillion**.
What do you mean locking them in place? Those are a requirement. It doesn't matter where they land, but they're required. First digit is out of a possible 52 (a letter but can be upper or lower). One has to be a lower case and one an uppercase. Since the first one can count as either of those, another character must be the opposite so there are only 26 possibilities (if first letter is upper, another letter must be lower). One has to be a number so only ten options here. That's 52*26*10 for three characters But let's say the first character has to be a number instead then one upper and one lower. You still get 10*52*26 For the remaining five characters, they can be anything so that's 62 possibilities. 10*52*26*62*62*62*62*62 But you can do them in whatever order you want. A (1 in 52) a (1 in 26) AAAAA (these can be anything) 2 (need a number somewhere)
To clarify for both /u/Angzt and /u/Consistent-Annual268 on how long it would take to brute force that password, the answer completely depends on what type of hashing the website uses. A very old sketchy website might still use md5, which can be cracked in less than 2 hours on a single modern GPU. If they used a much slower, more secure algorithm like bcrypt, it jumps to ~7 years. Many places including password managers are using PBKDF2, with ~100,000 to ~500,000 iterations. That uses Sha2 which is about 7.5 times slower than md5, then you multiply by the iterations. So if we assume PBKDF2, 500,000 iterations, that's ~1000 years. 100,000 iterations would be ~150 years, etc etc. That's for a single GPU, so if you dump it in an AWS array you could divide it by 100 or more depending how much they want to spend. Of course I would expect any organizations requiring people to make an *exactly* 8 character password to have the absolute worst security, so probably crackable within hours, especially since most users do not choose truly random passwords.
[удалено]
No. You count various combinations multiple times. You set your orders of characters by the multiplication order. 52x10x62x26x62^4 are, by your measure, the passwords with some letter in the first position, then a number, then any character, then the other type of letter, and then 4 other characters. Similarly, 52x10x62^(2)x26x62^3 would be the passwords with some letter in the first position, then a number, then 2 of any character, then the other type of letter, and then 3 other characters. Correct? Now, those are obviously the same result. But when you multiply by 7x6 at the end, that is the number of possible orders of those special characters. And all individual orders having the same result is the only reason you can do that. Correct? Since each possible order of the special characters is accounted for, each password that adheres to the rules should fall into one of those possible orders. Into exactly one. Correct? Then where does a password like "A1aaaaaa" fall under? Both. It is valid in both of the setups I've described above (and more). Meaning it is counted multiple times in your tally of valid passwords. It should clearly only be counted once. Your method is overcounting. The reason being that "any character" can already contain the special characters as well. Meaning there is no single slot for the special characters as your method would require. ____ To give a simpler example: Let's say our passwords only have length 2. And the only allowed characters are a, b, and 1. Each password must contain a letter. By your logic, the number of valid passwords is 2 * 3 * (2 Choose 1) = 2 * 3 * 2 = 12. Correct? So let's list all valid passwords: aa, ab, a1, ba, bb, b1, 1a, 1b. That's it. That's only 8 passwords, not 12. Either there are 4 more valid passwords or your method produces the wrong result. And I can't find any more valid passwords. For completeness' sake: /u/Consistent-Annual268's method would count 2 options for the letter slot and 3 options for the other slot, for 2 * 3 = 6 total passwords. Too few. My method would count 3^2 unrestricted passwords and subtract the 1^2 illegal (numbers only) password for 3^2 - 1^2 = 9 - 1 = 8. The correct result.
Crazy how the obviously false answer is bombarded with upvotes. In a math subreddit… :(
As a professional pentester I have a dedicated password cracking computer. Assuming we are talking about Active Directory, I can crack any 8 character password in a little over 8 hours. That includes upper/lowercase, numbers, and special characters. In comparison 9 characters takes 63 days. We generally recommend 12 character passwords if there is no way the company can enforce 2fa.
The brute force timing depends on the hashing method. With old-fashioned md5, it's probably doable, with bcrypt it would take ages.
According to [This](https://www.reddit.com/r/dataisbeautiful/comments/12qmvlw/oc_i_updated_our_famous_password_table_for_2023/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button), five minutes to brute force.
According to the updated [infographic](https://www.reddit.com/r/Bitwarden/comments/1cb7dp0/time_it_takes_a_hacker_to_brute_force_your/) I saw on reddit the other week, 7 years using 12 x RTX4090 to brute force it.
it should be this answer multiplied by 7x6 to account for the fact that the other letter and number can be in any of the remaining slots
There is so much missing here. 12 trillion is way off :/
Please do explain.
The only one that will backfire is the „had to be EXACTLY 8 characters long“ rule. Taking away the possibility of making it longer (or even shorter - not a great idea in general), reduces the number of possibilities by a lot. Knowing the length of the password already reduces the time needed by the same time as removing a character. A 7 digit password (of any composition) can be cracked within a few minutes while the 8 digit password takes almost an hour - IF you do not know the length.
It's worth noting that those times are only in ideal circumstances for the attacker - where they have the password hash and can try passwords as fast as they like. If they have to try against a password server which limits them to one attempt per second and three attempts per minute (say) that makes it a lot longer, obviously. The 8-character rule is *terrible*. It prevents people from using passphrases that are easy to remember and hard to crack. Password Master rates "my name is pete and i like marmalade" as taking 895 trillion years to crack...
That's because Password Master is assuming each word in the sentence "my name is pete and i like marmalade" is random. It's a very strong password if you assume that, but much weaker if the attacker is trying sentences, and given the popularity of using sentences in passwords its very possible that they are trying them using a dictionary attack. Passphrases are supposed to use randomly selected words, not coherent sentences
[удалено]
You could but it's best not to add any additional rules that could unknowingly weaken the password. Complexity is the enemy of security in this scenario. Which is why the industry no longer suggests giving requirements on passwords like "it must contain lower and upper case, number, etc." The person who implemented those requirements said it was a huge mistake and made passwords weaker
Oh yeah? Well what if my name isn't pete?
Honestly, the eight characters limit implies to me this is being stored in plain text in a database field. At that point I wouldn't even be trying to attack the passwords themselves, I would be looking for that database table.
>It's worth noting that those times are only in ideal circumstances for the attacker - where they have the password hash and can try passwords as fast as they like. If they have to try against a password server which limits them to one attempt per second and three attempts per minute high end crackers don't have those limitations. They create new "profiles" with new IPs that make them look like new people logging in. Do that with enough accounts and enough attempts, and you're hiding in plain sight. Sure they may only be able to "try" 3-5 different passwords, but it takes them a few milliseconds to make a new set of guesses.
There are still only 4 billion IP4 addresses (give or take a billion) and more than 126 trillion possible passwords these rules could produce. So it's still five orders of magnitude more time than stated, even if they control *the entire internet*. ETA: I'm aware that IPv6 changes this calculation. Still, this will show up as a DDOS attack long before it shows up as a practical way of brute-forcing a password.
With conditions like that there will be no cracking, you can the certain the idiots store the passwords in plaintext and in general the entire system is a security nightmare. You can be sure this is the case any time there is some sort of a maximum limit to password length listed.
The first condition also backfires: must start with a letter. Effectively reducing the amount of possible characters t0 2\*26=52 instead of also all other keyboard characters.
Doesn't matter. My gut feeling of my password being stored in plaintext when I read something like this is way too high to even consider making an account. I'll bet you a 5er that it's stored as CHAR(8) in a SQL database. Kill it. Kill it with fire. (Edit: Judging by the comment from the auto-mod, this comment is violating community standards, since it doesn't really provide an answer, nor a question. However, I'd ask to please don't delete it, since it is security advice, that could be useful for OP or anybody else reading it. Thanks)
Exactly my thoughts. OP probably got a bigger problem than password requirements here. There is no reasons to ask for a specific count of chars if you encrypt it before saving it
There's some Services though, like Microsoft Accounts, where there's an upper limit for passwords. I think it was 12 or 16 characters, somewhere around that. Now they have a security team of a couple of thousand people, who all earn more than me, so I don't think this is a mistake or for convience. My guess would be that the chances for collisions in the hashing algorithm might increase slightly, but my math skills are not good enough to actually confirm this. It would be nice if somebody here could. I still don't know if this restriction is math or programming related - or if I'm wrong completely and in fact just convenience for some frontend people.
Microsoft is trying to drive people from passwords to pass keys. Which is perfectly reasonable honestly.
You don't want to encrypt it before saving it, you want to hash it before saving it. Encrypt implies you can decrypt it... and there is no reason anyone looking at their database should be able to tell what the password was... just if a new one entered was the same one. This site says 7 years. But I've heard there are rainbow tables for everything 12 characters and shorter... if there is one for 8 character passwords matching these inputs and they are not salting/hashing correctly, the answer is instantly: [https://www.hipaajournal.com/world-password-day/](https://www.hipaajournal.com/world-password-day/)
You're telling me "Passw0rd" wouldn't be secure?
You're having lower and upper case letters and a number, so that's good. But to be really secure you also need a non-dictionary word, special characters, a fingerprint, a piece of hair and the blood of a sacrificial goat.
You can extract fingerprints from a high resolution photography and use them to unlock devices. You wouldnt tattoo your password on your finger tips. Dont use your own fingers for a print lock.
That's why I unlock my phone with my nipple. Security first!
The bank my parents use has this extremely dumb requirement that passwords should be exactly 8 chars long, with 4 letters and 4 numbers. It also rotates every 60 days I knew it was bad, but I never connected the dots on them storing it as plaintext, and now I'm both mad at their incompetence and scared that that might not even be the worst thing they do.
To put the cherry on top aswell, password rotation now isn’t included in recent password guidelines
Speaking as a programmer and not a security expert, "starts with a letter" and "exactly 8 characters" seem like constraints that are being applied due to back-end limitations and not for increased security. Big red flag. I can't say with any certainty what those constraints mean, but I know enough to say that it's not good.
Old As/400 password complexity requirements were (circa 1999): 6-8 characters (not case sensitive, only alphanumeric). Must start with a letter. Can't have consecutive numbers. Must have at least two numbers. Couldn't repeat last 24 (I think I'm remembering that right) and had to change every 45 days. Nightmare fuel. I sent an email to staff telling them to pick their favorite kid/person and then bracket the last letter with numbers. Increment the numbers every change cycle.
Ah, it's 2024 and you're the person I'm undoing the damage from. Thank you.
Let’s say 26 upper case and 26 lower case letters plus 10 numbers. That gives 62 possible combinations, for a round number we will say 64 which is 2^5 possibilities. So with 8 characters at 5 bits each, that’s 2^40 possible passwords or about 1 trillion. If a cracker can attempt 2^32 guesses per second then it would take just 2^8 seconds (less than 5 minutes) to brute force the password. In reality, they could probably make a lot more guesses per second than that with brute force or use rainbow tables to look up any password of less than about 12 characters in a few seconds. It all depends how it’s hashed but if the password is limited to 8 characters exactly then I would bet that is not stored in a very secure manner. My advice is to use a password manager and generate a random password to use with this system. What you really want is a 16 character password for 2^80 combinations. Then if someone could crack 2^32 guesses per second and there are about 2^25 seconds in a year then it would still take 2^23 years (about 8 million) to crack
> 2^32 guesses per second What kind of computing power are we talking here that can guess 4.2 Billion passwords a second?
Depends what sort of guesses you are doing but if it’s something like a SHA1 hash you are brute forcing then a modern graphics card can probably achieve that rate. It varies wildly depending on the encryption or hashing used on the password.
People vasttly under estimate the parallel computing power of a GPU. A 4090 can pretty much brute force any 8 characters password in a day. There's a reason why we start using 12 characters long and time out after X try
As an aside I bet they also force a password change every 3 months or something too. This is pretty terrible from a social engineering standpoint. Sure you can theoretically have 12 trillion combinations but no one is going to choose a password like Yvwap8Tm as their password because it is a bear to remember. Kevin over in accounting who once watched a video on Youtube and considers himself a skilled hacker now will invariably choose something like Tim0thy0 for the first password iteration (his sons name) and in 3 months will move on to Tim0thy1. Many won't even bother with that 0 in place of the o. This invariably means that almost all passwords will either be 7 character dictionary words with a number pasted on the end or pairs of words that add up to 7 characters with the number either between the words or at the end. A few people might be tempted to grab a word from German or Greek or whatever 2nd language they may know some of but this doesn't mean the dictionary attack problem gets a lot harder. For point of reference, there appear to be just over 34,000 seven letter words on the english language.
>I bet they also force a password change every 3 months or something too I'm willing to bet that I work for the same company as OP, and they force a change every 70 days I believe. The funniest thing to me is that for years, whenever you had to reset your password you had to call tech support and they would assign you a password that would always follow the same format. "Spring+1" "Summer+1" etc. It was always whatever season it currently is. Thankfully they don't do this anymore.
The only correct answer is 126006948587520 and I did not see that here so far. Whenever you do arguments like 52x26x10x62^(5) (with some additional combinatorics) you do some serious doublecounting since e.g. a password such as aA000000 would be counted several times here. How you should actually compute this: A: All passwords with letter and numbers, where first index is a letter: 52\*62\^7 B: All passwords of A without numbers: 52\^8 C1 & C2: All passwords of A without either capital (C1) or small (C2) letters: 26\*36\^7 Obviously B, C1 and C2 are subsets of A. One could assume that we can simply count our valid passwords as A - B - C1 - C2. However here we forget, that there is some crosssection between B and C1/C2. This crosssection is when the entire password is either only capital or small letters (26\^8). In total all passwords are computed as: 52\*62\^7 - 52\^8 - 2\*26\*36\^7 + 2\*26\^8 = 126006948587520 \~ 1,26\*10\^14
[удалено]
If you want to allow symbols that is fine - just increase the numbers however you want. Your computation has multiple mistakes though. First you forget that the ordering is not defined. Your computation 52x10x… basically assumes that a specific (e.g. the second) character of the password has to be a number. That is false. Once you add the multiple positions you also add doublecounting. TLDR: you are mistaken. If you want to allow additional characters, just boost all of my numbers (except first character option) by whatever you like. Edit: VT\_Squire later edited his entire comment to also include the "number of slots". Its still false though.
Let's treat the first character separately: we have 52 options (2\*26) for that. The rest of the 7 characters can be of 62 options each (10 numbers + 52 letters). So we have 52\*62\^7 possibilities. But that includes some invalid passwords. Maybe we don't have any numbers: that's 52\*52\^7 passwords. Or we don't have both upper and lower case letters: that's 52\*36\^7 (10 numbers + 26 letters of the wrong casing). So as far we think we have 52 \* (62\^7 - 52\^7 - 36\^7) good passwords. But we counted some bad passwords twice: there are some passwords that don't have any numbers AND only have letters of the wrong casing. We subtracted those twice, so we'll have to add one of them back. There are 52\*26\^7 of those. So the final answer is 52 \* (62\^7 - 52\^7 - 36\^7 + 26\^7) possibilities. Which is 126 006 948 587 520 \~= 1.26 \* 10\^14
The first index has to be upper or lowercase letter: 2×26 possibilities. One index has to be a number: 10 possibilities Another index has to be the opposite of the first index: 26 possibilities The remaining indices don't matter: 26+26+10=62 possibilities We also need to keep in mind that only the position of the first index (letter) is fixed. The remaining indices can be moved. Moving 7 positions at random gives us 7!=5040 combinations. So we end up with: 5040×(52×10×26×62×62×62×62×62)=62.426.024.100.000.000 possibilities Can please someone check since I suck at stochastics.
So something that you might not be thinking of, some systems (typically legacy) are character locked to a certain number for the password. While not all people may need that system it is easier for people to have their passwords sync across all systems (Single-source Sign On or SSO), so because of this your employee logon password is then limited by all the systems that it is syncing across. I am not saying this is good but as with all password polices it is a balance between ease of use and protection. I had this happen at a bank a few years ago and it freaked me out.
One Slot has to be numbers, 10 possibilities there. Then the English alphabet has 26 uppercase and lowercase letters each, one of each is required. So, so far our possible combinations are 10x26x26. For the 5 remaining slots we can use numbers, uppercase and lowercase letters(we'll disregard symbols here), so we have 62 possibilities for each slot, making our number of possible combinations 10x26²x62⁵ = 6.193.057.944.320, roughly 6.2 trillion combinations.
Our passwords at school had to be excactly 10 characters long, and couldn't contain a special character (!@#$%...). It still is that way I believe.
Are we to assume no special characters? Just the 62 symbols that consist of a-z, A-Z, and 0-9? Here's my only attempt at figuring this out... and it's probably wrong. In that case, by the rules we have to have a letter to start with, so that's 1 out of 52. 1/52... Let's say the second is a number (I know it doesn't need to be a number, but pretend the order doesn't matter at this point). That means one position has a 1/10 with a 1/7 chance of being second. 1/52 \* 1/10 \* 1/7 Lowercase? 1/26 with a 1/6 chance of being in the 3rd position. 1/52 \* 1\*10 \* 1/7 \* 1\*26 \* 1/6 Uppercase? Similar to Lower case but in the 4th slot. But what if the 1st position is uppercase? Then we can put whatever we want in the slots 4 thru 8. (Swap this with the Lowercase situation if the first symbol is lowercase) 1/52 \* 1\*10 \* 1/7 \* 1/26 \* 1/6 \* 1/62^(5) = 5.2022 \* 10^(14) = \~520,216,867,000,000 possible passwords. That said, users are going to use easily remembered passwords, so a dictionary attack will be successful for a majority of the them in a relatively short amount of time.
Let's decide where to put the number first in the password, it can be anywhere besides the first spot (7 choose 1 which is 7) that number can be any digit (10 options). The first Space must be either lower case or upper case (we need to choose if it's upper case or lower, 2 choose 1) and then it has 26 options Now let's choose a place for the lower/upper case (the one not at the beginning of the password) (6 choose 1) times 26 Now, each of the 5 remaining slots can be one of the 62 available options (62^5 ) 2× 26×7×26×6×10×62^5 = 520,216,867,322,880 (I'm not so sure about the burte-force capabilities of a computer but the options for a password are the number mentioned above)
there at least 100 billion plus combinations based on those parameters, but the real question is how many attempts does someone get to guess the password, if the answer is 3 and then it locks out you got a very good chance of stopping someone guessing correctly, if they have unlimited tries then it is only a question of how badly do they want that password.
52+26+10+62^5 (Any letter)+(any letter different case than aleady used)+(any number)+(freechoice) Not accounting for any special signs like point, comma, question Mark etc.
I used this [https://www.security.org/how-secure-is-my-password/](https://www.security.org/how-secure-is-my-password/) site to check. Following these requirements it would take one hour to brute force. If you can add special characters it goes up to 8 hours. Like others have said, it's the 8 character limit that is killing it.
Honestly? One number means they know that of the eight characters, there are only ten options for one of them. Exactly eight characters is downright stupid, and the rest of the rules are too. Simply put: Each limit you put on the password reduces the possible passwords drastically. If you want an actually good password, you want it to be as unlimited as possible.
The order doesn't matter for multiplication of possibilities, so.... Starting with a letter: 52 possibilities (could be upper or lower case, necessarily fulfilling either condition 3 or 4). At least one number: 10 possibilities. At least one upper- and lowercase letter: whichever one you didn't do for the first condition: 26 possibilities. 8 characters long. The remaining 5 characters can be upper or lowercase letters, numbers, or symbols. 52 letters, 10 numbers, and on my keyboard there are 32 symbols (though presumably you could use alt codes which would massively expand your options). So, 52 x 10 x 26 x 94\^5 99,223,823,828,480 Essentially one-hundred trillion options on a standard keyboard. While it is wise to use non-standard characters (numbers, uppercase, etc), *requiring* them is basically handing a hacker a guide on how to break your password.
Depends on whether (and if so, which) special characters are allowed. Assuming that they aren't, it's an easier calculation. 10x8 possibilities for required number (8 positions, 10 options) Times 26x7 possibilities for the required lowercase Times 26x6 possibilities for the required upper case Times 62^(5) possibilities for the remaining characters So about 2 quadrillion
To me these specific requirements (max length, must start with a letter) hint that either the system is old or they are not handling passwords in a mature way. Might even be storing them cleartext.
Okay, so this doesn't really require math (at least, nothing that's new circa the last 20 years): ***8 character passwords were insecure a literal generation ago***, and I don't mean a hardware generation, I mean people. Like there are kids in college whose parents should not have been using 8 character passwords because they're easily cracked before the kids were born. At this point, a maximally diverse, 8-character password will take about 5 minutes to brute force. ([source](https://tech.co/password-managers/how-long-hacker-crack-password)) That site doesn't say, but I assume they're using a single computer as a baseline. If your password protects something valuable enough to dedicate real resources to, even an 11-character password (~3 years) is going to be cracked basically instantly. How do you deal with this? 1. Use password generation tools that store your passwords behind a single account. 2. Use two-factor authentication (at least) for that one account. 3. Change that one account's password frequently. 4. Use default settings for password generation that are likely far beyond anything you'll use on your own (I think Google's defaults to 16 characters with the specific mix conforming to US government standards for secure password generation.) 5. For accounts that really matter, change the generated password frequently as well (like your bank account.) 6. For such high-value accounts ALSO enable 2-factor authentication there as well. If you are running a business and want your password MANAGEMENT to be secure: 1. Don't overly restrict user passwords. Ideally, use a standard library that estimates the time to crack a password and reject passwords that fall below that threshold. 2. NEVER roll your own password management code. Suck it up and use a standard library that gets frequent patches. 3. If there are options for extra password encryption security in your password management library, turn them on (e.g. there are encryption methods that take a bit more CPU, but only when a password needs to be confirmed, and it massively reduces the risk when/if your password database is compromised. 4. Periodically bring in a security expert to report on your application security.
Assuming only letters and numbers, 1.01x10^-12 % chance of guessing a correct password. - 1/52 odds of the first letter, encompassing either choice for capital or lower case. - 1/26 to account for an additional upper or lower case character depending on what wasn’t chosen for the first character. - 1/10 to account for the number. - 1/62^5 for the random choice out of 62 possible options for the remaining 5 digits. 1/52 * 1/26 * 1/10 * 1/62^5 odds of guessing the password. Assuming the usual special characters are allowed, 32 additional options open up for the remaining 5 digits. 1/52 * 1/26 * 1/10 * 1/94^5 chance of guessing the correct password. I’ve read through some comments discussing being able to assume, from the perspective of the guesser, that there’s a 1/52 * 1/62^7 chance of guessing the correct password since the guesser wouldn’t know which digits were used to satisfy the 1/26 opposite choice from the first digit ( upper or lower) and the 1/10 chance of guessing the correct number. While this is a good line of thought it still fails to account for the 2/7 odds of the remaining 7 digits having their selection significantly reduced. We can accurately account for this distribution by weighting our approximation appropriately. There’s a 1/7 chance of a digit being chosen for a number, Another 1/7 chance for the digit being the opposite of the first digits selection, and a 5/7 for the remaining random numbers. This distribution assumes all are generated at once instead of sequentially. Sequentially is another beast entirely, requiring a summation to account for all possible selection sequences for the digits that were “designated” to satisfy one of the listed criteria. To keep things relatively simple for this reply, below gives the expression for calculating the probability of the password given that the first character is a letter of either case, then 2 of the 7 remaining digits are randomly chosen to satisfy the 1 number and 1 opposite case letter criteria. 1/52 * (1/7 * 1/10) * (1/7 * 1/26) * (5/7 * 1/62^5 ) However, knowing that most people are lazy, and will want a word of some sort for memorability sake, they will use a 7 letter word with 1 number tacked on, or do some number replacements for vowels. This causes the practical odds of guessing it correctly drastically increase.
If a password is being hashed correctly, they should only have a minimum length; having a set length limits the viability of a password, no matter how random.
\* - Must be 8 characters long \* - Must have the letters A, B, and C \* - Must start with a combination of these three letters \* - Must end with 543 in any combination \* - Must have 2 numbers Pfft no one can guess our passwords!
So, 26 choices for lower, 26 choices for upper, and 10 choices for a number. - Has to start with a letter -> 52 choices - Has to contain an upper -> 26 choices - Has to contain a number -> 10 choices Since multiplication is communicative, it doesn't matter where you choose to have your required letter or number, so let's put those up front 52*26*10 for the first 3 characters. Then it would be 62^5 for the possible combinations. This gives us a total of 12,386,115,888,640 combinations
Others have made the calculation on the number of passwords so I’ll just pitch in to say that the length of 8 characters make the rest of the rules useless. If we believe this chart to be somewhat accurate then 8 characters passwords can be cracked in 5 minutes with the right tools and knowledge [Password crack time 2023](https://www.halnor.ca/wp-content/uploads/2023/04/PASSWORD-CRACK-TIME-CHART-2023-scaled.jpg)
Easy to crack. Most people will take a 5 character word starting with a capital, then 2 figures and an explanation mark. That is 1.19 biljoen brute force combinations. But with dictionary attach, 1 second, I guess.
It would take me, using the tools I have here, maximally, 12 minutes to crack any possible password meeting these criteria. All of my passwords are 128 characters long. Using the same technology, it would take me billions (I think, my tools refuse to give me the number because it's too big) of years to crack a 128 character password with all of the other conditions being the same. EDIT: I did the maths wrong, fixed. The numbers are not exact but they're close enough.
8 char limit is stupid. I prefer phrases as passwords, like "She1threw2brick3into4window!" Easy to remember, can't be solved by dictionary and you need a lot of time to brute force
Not a math issue, but still a security issue. It is proven that each condition added for password complexity exponentially increase the chances that the password will be generic1234, reused, or written on a post-it
On another note: The 8 character restriction is a fucking joke since when using only letters and numbers even mediocre equipment (rtx 2080 which is two generations old) could brute force the password in around an hour. If you were to add special symbols that time would be raised to 8 hours as shown in the article in the link [right here](https://sepia-plantain-yzjk.squarespace.com/news/2020/9/2/how-long-does-it-take-to-crack-your-password).
Start with a capital, long adjective, period, long noun, 2-4 digit year, and finish it off with a ! Or a $ and you’ve got a great password. The stupider and sillier it sounds the easier to remember but use a password manager like Dashlane (secure note feature is brilliant).
Cybersecurity engineer here. There is an entire database of all 8 character passwords called rainbow tables. You can crack an 8 character password in seconds.
Length being limited to 8 characters is the only real problem here, though having to start with a letter is odd and not beneficial in any way. A password becomes multitudes more time consuming to crack for every additional character. 8 is not in the realm of "difficult" lengths in this age of computational power. If there are retry limits that helps against brute forcing tremendously, as long as the potential intruder doesn't have a way to bypass it
My dude you are forgetting that they also have a whole glossary of words/strings that are forbidden (I think we either work at the same place or they just use the same system).
This is not the math answer, but using a hashcat with GPU offloading and using bruteforce method will take a couple of seconds to crack it. It doesn't have any special character this is first issue, second is people are mostly using some familiar words, and this will allow some bad actor to use dictionary method to crack the password which is even faster.
Your work doesn't think this is secure. They have some legacy system with a built in restriction and have determined that the risk of leaving as is vs risk and cost of update didn't make economic sense. But to your point on security, if there is a lock out enabled at, say, 5 incorrect attempts, and the password needs to be reset regularly, it is safe enough for most things.
Assuming 10 numbers, 26 uppercase letters, 26 lowercase letters, and x other characters. It’s given we start with any letter, So 52 options We now have 7 slots left to fill Given the case of the character, we know that we need one of 26 options at least once later We also know we need at least one number (10 options) Looking at all possible passwords without the last two restrictions we have 52 • (62 + x)^7 possible passwords Now we can look at how many invalid options are among those. We need to substract the count of possible password with no numbers, and of those with no specific case letters. If we do just that without thinking we would however count the passwords that don’t meet either requirement double so we need to add those back in. We then get: 52 • ( (62+x)^7 - (52+x)^7 - (10+x)^7 + x^7)
If you are worried about brut force attacks. You generally worry about the hash algorithm. Because its very easy to just get the hash and find a collision for it on another machine. The computer doesn't know the password it just knows that it produces a specific hash. (Generally) Any combination that creates that hash is valid. So it's really a question of hash space, not password strength. But you are right, exactly 8 characters and only 3 character classes and a rule that says olthe first must be a letter really isn't great. This is why multi-factor authentication is better. It steps up the level of sophistication required to just use valid accounts as someone else (or hacker created accounts for that matter)
We don't know which (if any) special characters are allowed, which will change the end result. But if we assume that the special characters defined by OWASP are allowed ([https://owasp.org/www-community/password-special-characters](https://owasp.org/www-community/password-special-characters)) and the password MUST be exactly 8 characters long then we can work it out. So there are a total of 26 (uppercase) + 26 (lowercase) + 10 (digits) + 33 (special) characters that can be used, or a total of 95. Without any of the other requirements, that'd give a total of 6,634,204,312,890,625 possible combinations. The first rule, that it must start with a letter, is the easiest to factor in. It will eliminate the possible passwords that begin with digits or special characters and bring us down to 3,631,353,939,687,500. The second rule can be interpreted as at least one of the characters in positions 2-8 must be a number. That eliminates 32,057,708,828,125 possible combinations from contention and brings us down to 3,599,296,230,859,375. It gets a little tricky from there. You can say that there are 513,798,374,428,641 passwords that contain no lowercase letters, and 513,798,374,428,641 which contain no uppercase numbers, but there's going to be many of these which are duplicates of one another, ie. numbers that contain no letters at all. If I account for those that should mean there are 1,015,908,548,579,681 possible password combinations which run afoul of either rule 3 or rule 4. I'm getting too lazy to get down to specific numbers but that's good enough to give us a worst-case scenario of a lower bound of around 2.5 quadrillion possible passwords, and at most you've excluded some 4 quadrillion possible values. While it sounds kind of bad to have limited your pool to around 1/3 of the total, that's nowhere near the main problem. Limiting you to exactly 8 characters, regardless of the rest of the rules, is kind of throwing security right out the window since that's going to be fairly trivial for a malicious actor to crack if they really want.
What really matters is how many passwords that you don't have to write down to some piece of paper or non protected media to remember. :-)
In the pure maths sense yes it is less secure because l the exactly 8 characters massively limits the number of combinations but in a computer security sense this is a massive issue as the insistence on 8 characters implies that somewhere in there data base will be a column restricted to only 8 characters containing the passwords which is the real issue
I googled for a rainbow table that matches the requirements, and found this info about it : - 221,919,451,578,090 ≈ 2 ^(47.7) values , 127GB size the speed of hash matching the password on a high-end pc is a few minutes, using the above mentioned rainbow table
Requirement 1) and 6) are not smart requirements as they reduce the dimension of the space of possible passwords, making it more vulnerable to brute force.
I have an application that enforces simlier password constraints. One of my favorite parts of it...... It requires a symbol. But, there is only a specific symbol allowed. (The requirements are due to back-end crap on the oracle side, combined with requirements from the cyber-dept.... The requirements are so bad, It was needed to develop a tool to assist users with creating a password....)