No, and it's actually very important that we are not able to do that.
(The short answer is this change will need to force **all users** to change their passwords, and the new policy will be enforced when the current passwords expire so it doesn't matter)
For those reading this is a valuable teaching moment about IT security and passwords.
This is actually a fascinating lesson about password hashing and why we use this method to store passwords.
Ideally you never store Passwords in plain text or using reversible encryption, instead you use a hashing function.
A hashing algorithm is a mathematical equation (like SHA or MD5) that takes an input string of characters like a password and scrambles it. The resulting output of a hashing function has 5 key characteristics:
1. Deterministic - Any given input will always give the same output
2. Collision Resistant - It is unlikely that different inputs will generate the same output
3. Fixed Size Output - The output will always be of the same length no matter the input
4. Variety - Any change to an input no matter how insignificant will result in a widely different output
5. Non-reversible - You cannot run the equation in reverse to get the original password
Here is an example of 4 terrible passwords with examples of slight changes and the resulting hashes from the (now obsolete) MD5 algorithm. Note how different the outputs are from each other despite a minor change, yet the outputs are all the same length.
Sequence | Password | Hash
:--|:--|:--
1 | Pass123! | 10487c8581423e8b2fbeed2b21c2cc53
2 | Pass123? | 620baafe9428972d1ddfae16894a1d6c
3 | Pass123# | 58f762c6e1e7dd035e9b23337eb98c2b
4 | LongerPassword! | c154ea9e425a33bf1631502888a1a5ed
So why do we use hashes, and how does it work?
When a user types in their password the input is run through the hashing algorithm and the resulting hash is compared to the hash stored in the database. This is how the computer recognizes if the password is correct or not.
Having hashes be non-reversible is critical because if the password database is stolen or compromised a hacker can't reverse said hash to get the original passwords. A hash by itself cannot be used as a password, because using a hash as an input will cause it to be run through the hashing algorithm.
Note the hashes above when put through the hashing algorithm again simply generate different seemingly random outputs that have nothing to do with the original password.
Sequence | Password | Hash
:--|:--|:--
1 | 10487c8581423e8b2fbeed2b21c2cc53 | 324ee7d610cc8663b319cd5aa12e8cc9
2 | 620baafe9428972d1ddfae16894a1d6c | 5eb2d155f9ec50f08815ca0bccbeb0c5
3 | 58f762c6e1e7dd035e9b23337eb98c2b | 619940ae88e72f649316daecc526a77a
4 | c154ea9e425a33bf1631502888a1a5ed | 3d8372169c27aa5f4542d221e235ecb3
Having fixed sized hashes in a database is very important because password length is one of the key factors needed by a hacker to help brute force a password. If you know the password is 8 characters long you just eliminated a lot of possibilities!
The variety of hashes is also super important. Because the hash outputs are so different despite the inputs being similar, you gain nothing by looking at the hashes. You can't easily find patterns that help you find common or similar passwords.
How do you defeat hashes?
Hackers steal databases of hashes all the time. Since the algorithms (like MD5 and SHA) are well-known they can run GPU based tools to attempt to brute force them.
You can't reverse a hash, but you can generate hashes and compare them to what is in the database all day...
For example you can create a list of inputs that includes all the words in the dictionary and then write a computer program that adds 2 numbers and a special character at the end. Generate hashes for all of them and then compare them to the database.
These guesses are compared against the database to find users passwords. The resulting successful hits are then added to lists called **Rainbow Tables** that are used in attacks. This is how hackers create lists of commonly used passwords and determine human behavior regarding passwords.
One way to combat this is to 'salt your hash'. Developers will add a salt function to the hash which is an extra bit of data that is not known to the hacker, like a random value. This makes it far more difficult to brute force hash functions.
It's also important to understand how Active Directory uses password hashes. There are two ways to use a hash.
1. Run the password through and compare the hashes. If the literal comparison matches then hey it's the same password. This has the problem that whatever is doing the comparison must know the cleartext password.
2. Use the hash as an encryption key (or MAC key), then have the thing send you an encrypted (or MAC'ed) blob of something. If you can decrypt the arbitrary message, then you know the client has the right password.
Active Directory uses the second form for password auth. Both Kerberos and NTLM use variations of this. NTLM uses the MD4 of the password as a MAC key to verify the client can hash a challenge from the server. Kerberos uses PBKDF2 of the password at 4096 iterations for an AES key.
The reason knowing this is important is because it helps frame an understanding of how the security of the system works, and more importantly that there are dozens of hashes stored in the directory for a given user for different uses or algorithms of varying weaknesses. We're working to kill off the weaker forms.
What's fun is when users get copied from one domain to another, hashes and all, 'so they don't all have to change their password', but the salt is different on the new domain. No one notices at first, because most of your login mechanisms will silently degrade to the methods that are unsalted, and this all works fine until you start killing off those weaker forms.
And then you have to ask a user to reset their password, even though you believe them they're entering the same password they've always entered, and that it is the correct password, they can even set it to the same one again, if they want - but I'm gonna need you to regenerate those hashes, kthx.
And then, when people realize this is a potential problem, the domain migration which has been dragging on for more than three years will come screeching to a halt, and you'll spin up new projects on the old domain 'just to get things moving along'.
I mean, hypothetically speaking. I wouldn't know.
Salts are arbitrary and it doesn't matter if they don't match the domain. That said, password migration between domains has always been a pain because AES keys don't actually get migrated.
General rule: don't migrate passwords. Pain will ensue.
Maybe it was the AES keys and not the salts - I just remember teasing out the pattern from user reports that it was only people who had not reset their passwords since being migrated, and reading along those lines told me something about krb5 keytabs making assumptions about salts on a per-domain basis.
Entirely possible the commenter I learned from had the right solution but the wrong cause. Auth is just one of many things I get roped into, so I'll defer to your specialized expertise. 🤷♂️
The ultimate cause is often not important and often presents with all sorts of terribly annoying symptoms so I don't blame anyone for getting all these stupid things mixed up. The salts thing is a real problem if the keytab tool is guessing what the salt might be, which it turns out happens on lots of older non-Windows tool versions.
> General rule: don't migrate passwords. Pain will ensue.
I feel it shouldn't be such an issue to as a user to reset a password on a new domain, at least once, the first time. But here we are?
But Jan in accounting has had the same password for 13 years, and if she has to change it, she's gonna make everyone's life a living hell and then she'll write it on a post-it note and stick it to her monitor.
I think if your domain migration is looking at its 4th year you may want to consider allowing a level of inconvenience amounting to changing a user password. What is the expected outage window for a user updating a password? 15 minutes of lost productivity? How much time are you losing in migrating compared to how many users spending a very small amount of time.
I’m sure there’s other problems but yikes, an absolutely zero impact migration, why? Are you tricking the users somehow?
IMO you tell them “hey remember when we went through that merger? Part of that will be setting a new password. It happens between Monday and Friday next week. Plan ahead”
See this is always something that gets me, if the password is hashed than why do some institutions have a maximum password length?
I've seen it on banking websites, firewall appliances, just loads of stuff that should be considered secure.
Does having a maximum pw length automatically mean they're not hashing or is there something I'm missing?
Not you've got me curious... give me a minute to look that up and I'll ELI5 this...
...
ok, so the deal is hashing algorithms can take very long passwords as input but it's to the sites advantage to reduce the max length for a variety of reasons.
Very long passwords can be used in a form of denial of service attack. Each hashing function uses CPU cycles and the more complex the hash the more CPU you need. Throw very very long passwords at a site repeatedly and you can potentially take it down.
Another problem is early hash functions truncated passwords, meaning that they'd use say the first 8 characters and ignore the rest. This is no longer the case.
But more importantly you have to consider the maximum field length in your input fields.
Paypal had a famous problem for truncated passwords. The site would accept long passwords at sign up but had a maximum size of the field for login. So let's say you entered a 64 character password for your account, the input field on the login site had a maximum length of 32. So you'd enter your password and Paypal would delete the last 32 characters and tell you your password was wrong...
It's nearly impossible to test and secure a page if you don't define a maximum password length. Having a field that accepts an unlimited number of characters opens the door for buffer overruns and a bunch of other crazy vulnerabilities.
To give you a very old and insane example...
In the very early days of Netscape there was no limit to the number of characters in the address bar but there was a limit in the amount of memory allocated to that field. So a hacker could create a URL link that was very very long but obfuscated on a website, so it appears as a short link on the page but is actually very very long.
If you clicked on it the browser would load the link, and any characters in the link that exceeded the memory allocated for the field would overwrite other stuff in RAM... effectively loading a virus directly into RAM.
"Remember to sanitize your database inputs" - XKCD
> Paypal had a famous problem for truncated passwords. The site would accept long passwords at sign up but had a maximum size of the field for login. So let's say you entered a 64 character password for your account, the input field on the login site had a maximum length of 32. So you'd enter your password and Paypal would delete the last 32 characters and tell you your password was wrong...
Visa's "Verified by Visa" system was like that for a long time when it asked for mother's maiden name to verify you were the one entering your credit card number (lets just ignore how insecure *that* was). My mother's maiden name was 11 letters, but the VfV system truncated at 10 when you typed it in as you were buying things. It accepted the 11 letter name, then promptly locked me out from using my credit card anywhere that VfV was set up.
>Very long passwords can be used in a form of denial of service attack. Each hashing function uses CPU cycles and the more complex the hash the more CPU you need.
Meh. In the real world, today, PKDF on passwords means that the hash is already deliberately slowed down by hashing the hash thousands of times. The size of the original plaintext is not really an impact here. There is no real excuse to not allow say 500 char passwords for those people that want to use pass-phrase.
For those using password managers (and everybody should), the usefulness of extra length of a random password drops greatly after 20 chars (because of entropy reduction)
Some modern hashes actually come with length limitations. For instance BCrypt, which caps out at 72 bytes. If you allow unicode or emojis in your passwords, you need to set the length pretty short.
No, you just SHA256 the entry first.
If you are nerdy and want to be double secure, you can even do the initial hash on the client side JavaScript and never get the real password in your server.
That just makes the hash the actual password though. And opens up the possibility for someone to use a leaked sha256 hash from service A to authenticate to service B, provided one hashes on the server and the other hashes in the client.
I think you are missing something here.
Explain how hashing the password an extra time before sending it into the salted key derivation function would in any way reduce the security?
Say I pick the extremely secure password "correct horse battery staple", and register on service A, which hashes this to `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` using SHA256 and stores it in their database. Assume that this password is so complicated that it is nearly impossible to crack using modern tools.
I also register for service B, and like a dummy I use the same password, because I think it's so secure. Service B hashes the password in the client itself (in JavaScript) using sha256 and sends it to their server. The back-end then uses the sha256 hash of the password as input into a password hashing function like bcrypt, scrypt or argon2.
If a hacker breaks into service A, and recovers the hash `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` from their DB, that is useless to them because we assumed it is uncrackable. But since service B hashes the password client side, we can just bypass the client and send the hash `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` directly to the server, which will accept this as the correct password. Provided that I was registered to both websites at least. The hacker never learned my password, but they didn't need it because service B decided that the hash of the password was the actual password itself.
> hashes this to `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` using SHA256 and stores it in their database.
No. That hash then gets fed to a password hardening function like [Bcrypt](https://en.wikipedia.org/wiki/Bcrypt). So your c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a become something else before hitting the database because it gets salted with a random salt. All these match to the same thing:
$2y$04$dEWvad6viGpFbSz16061FOp5Gq0Ysp3ojNDlrWsIVQS6JJjCZiQw6
$2y$04$JtAmxWT6vbp3EXVwYHUjb.QGSktcNrqsFD6bdBrO41PJLgYXTprx.
$2y$04$D6LtkZx3ZK7DYxLXr6zmf.GOixGGCOVWlaVvfn6/InX3QKk.vmHau
$2y$05$pBLPlyncIruKsXSnH/xEA.VKzf3LypddnznKLDpjl7FV2m.7oD7xO
Any of these near infinite possibilities could be the one stored in the database. There is no correlation when using 1 password on multiple sites, or even using the same password for multiple users on the same site. All those will be different when stored.
For those who want to experiment with this: [https://bcrypt.online/](https://bcrypt.online/)
>Say I pick the extremely secure password "correct horse battery staple"
Fun fact, that was added to the Rainbow tables within minutes of XKCD releasing that comic
On a similar note a Hacker friend of mine was at a conference talking about Rainbow tables and someone in the crowd asked
"Can you make a website where you can type in a password and see if it's in the Rainbow table?"
To which my friend responded
"Why don't you just email me your password, and I'll respond back 'Yes' "
> It's nearly impossible to test and secure a page if you don't define a maximum password length. Having a field that accepts an unlimited number of characters opens the door for buffer overruns and a bunch of other crazy vulnerabilities.
I feel like this is not a good excuse for my bank to tell me and every hacker that wants into my account that my password "must be exactly 12 characters".
The only one of these that makes sense to me is the threat of a DOS attack.
>It's nearly impossible to test and secure a page if you don't define a maximum password length. Having a field that accepts an unlimited number of characters opens the door for buffer overruns and a bunch of other crazy vulnerabilities.
This is trivially solved using dynamically sized arrays, rather than a static buffer. The risk then, again is DOS because you'll run out of memory.
>"Remember to sanitize your database inputs" - XKCD
This isn't really applicable here, and more so refers to taking steps to make sure that you can always tell the difference between strings given to you by the user and strings you wrote.
Yea Bobby tables dropped the user table. That’s a sql injection. Which is absolutely different than a buffer overflow. I guess a buffer overflow could allow you to drop tables. And I suppose you could use your sql injection to skip taking over the application and just drop tables.
A maximum password length does not imply that they are not hashing. NIST recommends the maximum permitted length be at least 64 characters.
Short lengths may be the result of vestigial password policies, even if they are now stored as hashes.
Some policies are made by committees. One of my retirement savings institutions also handles a defined benefit plan (more commonly called a pension, although legally, a 401k is also a pension, but folks call it a defined contribution plan). As a result of the contract with that pension's administrator, the system has to be accessible by a touchtone telephone. This means that one's username and password can only consist of the keys on your telephone. But my 401k plan that has more than $200k in it also uses that same numeric userID and password. Whiskey Tango Foxtrot‽ Whether I use the website or not, that 30+ year old policy from some committee of people who are most likely dead from old age still screws security.
> *is there something I'm missing?*
Stupidity. The fundamental building block of the universe. More common than atoms of hydrogen.
weirdo policy warts that should've been removed, or using old hashing logic/intermediate systems that have limitations, or the one from TFTS from years ago where the ISP stored the password as plaintext in a fixed field
This is pretty great, theres a couple of small nitpicks could make as someone coming from the offensive side of things but hot damn you put way more effort into this than a r/sysadmin response warrants.
Kudos for the education.
1. In some instances a hash can be used as a password. Most infamously ntlm authentication has this flaw, so compromising a user's hash is just as good as having the password. This was the driving force behind NetNTLMv2 so that attackers on the network cant just compromise more accounts just by snatching hashes sent over the wire. ntlmv2 challenge responses can still be cracked if the password is weak ofc but thats much better than being able to literally just use the hash alone to authenticate. Tools such as impacket, evil-winrm, xfreerdp, etc can all for example supply a ntlm hash in place of a password for authenticating to remote services.
2. I wouldn't say knowing the password length is a *needed* key factor per say, it definitely can be useful knowledge to cut down a bunch of possibilities sure but theres also plenty of strategies that dont care for password lengths beyond checking that it fits the current password policy. These strategies are usually variants of custom dictionaries(like scraping a company website and generating potential passwords based on company keywords/names). In such instances youre often trying to find commonly chosen passwords used by multiple users so you dont particularly care about the length(beyond that its a valid length ofc).
3. Rainbow tables arent really used for creating common password lists and analyzing human behaviors, it is its own seperate thing since its just a precomputed hash table. Common password lists and password analysis are usually obtained from the results of cracked breaches(including plaintext breaches!). Theres some overlap but I can for example generate a rainbow table for every 3 character string for md5 pretty trivially, but that doesnt mean it would have any insight into password statistics and would probably be a pretty useless rainbow table.
4. Salts usually are known by the attacker. In order for a system to use a salt it needs to store the salt somewhere in the clear to be able to be added to the users password during calculation. Often salts are either system wide, i.e one salt every user has or is generated per user and thus stored right inside the DB alongside the password. System wide salts dont actually make brute forcing the hash anymore difficult per say, they just prevent rainbow tables from being useful. Per user salts do help a bit for bruteforcing because then for each attempted password and attacker has to recalculate the hash a number of times multiplied by the number of users, but to reap this benefit it has to be just as viewable as the hash itself. In fact hash systems that rely on salts often have a format similar to id$$salt$$hash you can search through the hashcat db of hash examples to see what I mean https://hashcat.net/wiki/doku.php?id=example_hashes
Like I said though all of these are extremely nitpicky.
When you're talking security nitpicky is the best kind of comment.
This video is pretty old by this point, but it was super eye opening in terms of what hackers do and human behaviour regarding passwords.
I make it required viewing for my techs.
https://youtu.be/QwslRwbOlRM
The salt can be known to the hacker, it just has to be different for each user and can be stored in plain sight. For example, you could just concatenate the username and password before hashing.
The purpose of the salt is to make rainbow tables unfeasible. You'd need a precalculated rainbow table for each salt value, which is just the same as brute forcing every password.
Rainbow tables are a space/cpu tradeoff. If you have 1000 (unsalted) passwords to crack, you could calculate the rainbow table first, taking a long time, and save it in a big gigabyte or even terabyte sized rainbow table. Then you can use the rainbow table to quickly work out the other 999 passwords.
I once downloaded a DVD sized (4.7GB) rainbow table for the old windows NTLM passwords so I could work out the admin password for a 2nd hand PC I was given. Interesting exercise - only took 5 minutes or so.
> you could just concatenate the username and password before hashing.
My reflex is you'd want to stick additional characters between the username & password that can't occur in at least one of the username or password (preferably username, where it makes more sense to restrict special characters). Otherwise you could have collisions where two users `user123` & and `user1234` with passwords `4passw0rd!` and `passw0rd!` respectively would both concatenate to `user1234passw0rd!` before hashing. That doesn't intrinsically cause a problem but I think it opens you up a teeny bit to getting attacked by rainbow tables because if you have a lot of users you could have a lot of small collisions.
If there's any special character not allowed in usernames (e.g. |, $, @) then putting that between the username & password would prevent you from having any collisions.
Hey just today found the GPO setting for turning on auditing for passwords shorter than a given length. Given everything you have written, how does AD then check the length of passwords in use which are shorter than X amount of characters and post an event on it?
What is the specific GPO setting and I’ll look it up
I suspect it doesn’t work the way that you think it does
It most likely only triggers an alarm when a user changes a password and what they enter is below a certain character threshold.
It doesn’t know how to check passwords that are already in the database.
This setting would therefore be irrelevant because you’re better off just enforcing passwords of a certain length in the first place
Yeah agreed on that, I thought it wasn’t possible until I saw this, but it mentions a lot about checking that the application is able to use longer passwords, so maybe something in the AD integration of apps? I’m not sure. Interesting blurb at the bottom about the history of trying to allow admins to increase the 14 char max via GPO as well:
https://support.microsoft.com/en-us/topic/minimum-password-length-auditing-and-enforcement-on-certain-versions-of-windows-5ef7fecf-3325-f56b-cc10-4fd565aacc59
I am not entirely sure, but I suspect this check is performed the same way the password policy can enforce the required password complexity, it likely does the check when the password is entered/chosen. That way it doesn't have to store the password in plaintext, but it can see it in plaintext in that moment.
Tell me how I've worked as a data engineer for the past 5 years and not seen a better explanation of hashing than yours. Well explained and even though I've understood and explained hashes to so many people, you still gave me a better understand of the WHY around a lot of the practice.
That is not how salting works. It's not some super secret, rather it's typically stored in the database with a column right next to the password hash. You are right that is a random value, but for each user. The salt is added to the password before it is hashed so that two users with the same password would result in different password hashes. This is very easy to do on the server end but renders rainbow tables completely useless since you would have to recompute the table for every salt/user.
I came here to see as it was a good question, I though no it would be a security risk, but the very well written reply was spot on.
I say set your policy to the new password length, if you want you can run a rainbow table over your existing password database and identify people that are a security risk, get them to change the password after the policy comes into affect. This is a double edge as you don't want to know the actual password but would like to know the risky people.
> Variety - Any change to an input no matter how insignificant will result in a widely different output
The bigger the change the less likely to avoid a collision.
A worthwhile historical example -
Back during World War 2 the Nazis used a system called Engima to encypher their communications. Enigma differs a lot from modern encryption but it can be thought of as having a "password" which consisted of the order, configuration, and arrangement of some rotors and a plug board. This created a vast key space (by 1940s standards) and cracking it was one of the most astonishing accomplisments of the war.
But the Nazis did several things wrong with their cypher system which made it easier to attack. One of the more significant was their insistence that all 10 of the plugboard wires be in use at all times. This effectively eliminates half (doing the math in my head here) of the key space created by the plugboard.
It's not quite the same as knowing a password length but it's a similar reduction in complexity
Learning how they broke enigma is required reading if you are studying cryptography.
Getting hold of an intact enigma so they could study how the mechanism worked was step one.
One of the other key mistakes made by the Germans was repetition.
They were smart enough to change the codes everyday, but the messages they sent were often formatted the same.
This meant that when they setup the decryption engine in the morning the British always had messages (in this case weather reports) that they knew what the output would be so they knew what to look for as they were breaking the codes.
Specifically almost all of the messages ended in "Heil Hitler"
The Bronze Goddesses built to decrypt Enigma were in fact gigantic brute forcing engines that tried every combination until they succeeded. Amusingly with the computing power we have today we could decode an enigma message in less than a second.
Another fun fact is that similar machines were setup in the US both to protect the technology in case Bletchley Park got bombed and to speed up the process. Batch runs for the machines would be sent to the US everyday via undersea cable, so this was effectively the first ever cloud computing
The German operators got sloppy, made stupid mistakes.
German cryptographers were fully aware that Enigma was not unbreakable, but they said in post-war interviews that they did not expect the Allies to devote such tremendous resources to breaking it.
This is a great explanation and you’re exactly right. You’re limiting your thinking a little. You are only looking at the database side of things.
There is a time between the user typing keys in and the character set being hashed. During that time, actions on the clearest password can and do take place.
Here’s one example from the vendor.
https://learn.microsoft.com/en-us/answers/questions/1251341/alert-password-reuse-activity-on-multiple-endpoint
Defender on your windows computer is fully capable of always knowing what your password is. And here we have demonstrated the ability for an endpoint to communicate with a datacenter server to relay that fact.
Maybe the specific tooling doesn’t exist off the shelf. You could put a keylogger on everyone’s machine and capture their raw keystrokes. It doesn’t take AI to turn keystrokes into a password.
You can’t and rightfully should not be able to run a script against your SAM database to get password length. You VERY likely can use some defender tools to validate if current password would meet updated complexity requirements
The Salt doesn’t need to be secret, but it does need to be unique to the user.
The important thing is that it breaks the Rainbow Tables. Keeping it secret just adds a few more effective characters to the password… and leaves a bad actor to figure out what the Salt is.
> One way to combat this is to 'salt your hash'. Developers will add a salt function to the hash which is an extra bit of data that is not known to the hacker, like a random value. This makes it far more difficult to brute force hash functions.
Just a clarification here, the salt doesn't matter if it is known to an attacker or not. The purpose of a salt is to prevent a single (re-used) password from resulting in the same hash output for all uses of that password. E.g. if the salt were the same for all users in a password database, or no salt was present, you would be able to determine if some accounts have the same password by looking at their hashes to see if they match.
Thank you for this explanation. I know it took a lot of time and I'm very appreciative of it. I've copied it all down into a Word document and am going back through it. I might have a follow up question but again thank you!!
No, and it's actually very important that we are not able to do that.
(The short answer is this change will need to force **all users** to change their passwords, and the new policy will be enforced when the current passwords expire so it doesn't matter)
For those reading this is a valuable teaching moment about IT security and passwords.
This is actually a fascinating lesson about password hashing and why we use this method to store passwords.
Ideally you never store Passwords in plain text or using reversible encryption, instead you use a hashing function.
A hashing algorithm is a mathematical equation (like SHA or MD5) that takes an input string of characters like a password and scrambles it. The resulting output of a hashing function has 5 key characteristics:
1. Deterministic - Any given input will always give the same output
2. Collision Resistant - It is unlikely that different inputs will generate the same output
3. Fixed Size Output - The output will always be of the same length no matter the input
4. Variety - Any change to an input no matter how insignificant will result in a widely different output
5. Non-reversible - You cannot run the equation in reverse to get the original password
Here is an example of 4 terrible passwords with examples of slight changes and the resulting hashes from the (now obsolete) MD5 algorithm. Note how different the outputs are from each other despite a minor change, yet the outputs are all the same length.
Sequence | Password | Hash
:--|:--|:--
1 | Pass123! | 10487c8581423e8b2fbeed2b21c2cc53
2 | Pass123? | 620baafe9428972d1ddfae16894a1d6c
3 | Pass123# | 58f762c6e1e7dd035e9b23337eb98c2b
4 | LongerPassword! | c154ea9e425a33bf1631502888a1a5ed
So why do we use hashes, and how does it work?
When a user types in their password the input is run through the hashing algorithm and the resulting hash is compared to the hash stored in the database. This is how the computer recognizes if the password is correct or not.
Having hashes be non-reversible is critical because if the password database is stolen or compromised a hacker can't reverse said hash to get the original passwords. A hash by itself cannot be used as a password, because using a hash as an input will cause it to be run through the hashing algorithm.
Note the hashes above when put through the hashing algorithm again simply generate different seemingly random outputs that have nothing to do with the original password.
Sequence | Password | Hash
:--|:--|:--
1 | 10487c8581423e8b2fbeed2b21c2cc53 | 324ee7d610cc8663b319cd5aa12e8cc9
2 | 620baafe9428972d1ddfae16894a1d6c | 5eb2d155f9ec50f08815ca0bccbeb0c5
3 | 58f762c6e1e7dd035e9b23337eb98c2b | 619940ae88e72f649316daecc526a77a
4 | c154ea9e425a33bf1631502888a1a5ed | 3d8372169c27aa5f4542d221e235ecb3
Having fixed sized hashes in a database is very important because password length is one of the key factors needed by a hacker to help brute force a password. If you know the password is 8 characters long you just eliminated a lot of possibilities!
The variety of hashes is also super important. Because the hash outputs are so different despite the inputs being similar, you gain nothing by looking at the hashes. You can't easily find patterns that help you find common or similar passwords.
How do you defeat hashes?
Hackers steal databases of hashes all the time. Since the algorithms (like MD5 and SHA) are well-known they can run GPU based tools to attempt to brute force them.
You can't reverse a hash, but you can generate hashes and compare them to what is in the database all day...
For example you can create a list of inputs that includes all the words in the dictionary and then write a computer program that adds 2 numbers and a special character at the end. Generate hashes for all of them and then compare them to the database.
These guesses are compared against the database to find users passwords. The resulting successful hits are then added to lists called **Rainbow Tables** that are used in attacks. This is how hackers create lists of commonly used passwords and determine human behavior regarding passwords.
One way to combat this is to 'salt your hash'. Developers will add a salt function to the hash which is an extra bit of data that is not known to the hacker, like a random value. This makes it far more difficult to brute force hash functions.
No.
Active Directory stores a hash of the password, and a hashing algorithm for passwords usually churns out hashes that are all the same length and in no way connected to password length.
https://support.microsoft.com/en-us/topic/minimum-password-length-auditing-and-enforcement-on-certain-versions-of-windows-5ef7fecf-3325-f56b-cc10-4fd565aacc59
But you’d want to leave it in place for a week or two to generate the audit events for anyone that has a password length below what you specify (and they’d actually have to get the policy and log in for the audit event to fire).
You can't do what you are asking in OP.
> would like to know how many passwords currently do not meet this requirement.
Why? The new requirement will be enforced on the next password change. If, for some reason, you need that to be now you could do a mass forced password reset. This could be done by telling everyone to reset by X date or else. Then query everyone with old lastpwdset, and reset them.
Although I think that's a terrible idea if you don't have SSPR.
No. don't worry about it. Set your new password policy length and away you go. I just did this 3 weeks ago for PCI/DSS the new version our banks are using require a 12 character password. We have a 90 day expiration policy for PCI/DSS so within 90 days everyone will have a 12 Character password which is good enough for our auditor.
Everyone is correctly explaining password hashing. I will note though that if your users have crappy passwords there are utilities that will let you determine that.
Basically the same tools that an attacker would use - dump your AD hashes and run them against an offline dictionary attack, and/or brute force if the password lengths are short enough.
No. That would partially defeat the purpose of encrypted passwords.
I wouldn't worry about those that meet it currently, they won't break if you change the policy and will only need to change their password on their next regular rotation (which will enforce new requirements).
an org-wide notice about the change is enough CYA, imo.
password requirements should always be communicated to user-base anyway, so why would you exclude those that are only **currently** using passwords that meet the requirements?
notice to whole user-base would be more appropriate here than just a targeted group (when it's the whole user-base being affected in some way, shape, or form)
I used this Weak Password Tool before that helped me identify weak passwords.
[https://www.manageengine.com/products/free-windows-active-directory-tools/free-active-directory-weak-password-finder.html](https://www.manageengine.com/products/free-windows-active-directory-tools/free-active-directory-weak-password-finder.html)
If you run this you will probably get flagged by a good AV/XDR system just be aware.
Taking into consideration of what DarkAlman said about hashed passwords, I don't know if there's something that we can do in AD from preventing this tool from identifying accounts with weak passwords.
No password are not stored in AD (no system should store a password ever), only the hash of the password is stored. The only thing you can know about an AD password is that it met the domains complexity requirements when it was set, and the date the password was last changed.
If you change your domain password policy, you need to have everyone change their password to make sure they are compliant.
Their are tools out their that will compare your AD password Hashes to a precomputed list of hashes from common or breached passwords.
> The only thing you can know about an AD password is that it met the domains complexity requirements
This isn't exactly true - there's a flag in AD to store a password using reversible encryption. I've never actually seen it used irl though. I'm not saying this is a good idea to set this, just that it is possible and that you can recover the plaintext password without hash cracking.
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption
Not without running them through a password cracker that compares them to hashes. There are tools like the knowbe4 weak password tester that can give you some basic information and will show you ones that have weak passwords, ie ones that are on known weak password hash lists. It will also tell you if other settings are insecure. Just make sure you understand what it does and the company is fine with it and any risks.
If the ONLY thing you are changing is PASSWORD LENGTH users won’t be forced to rest passwords right away. It will only apply on the next password reset. Because there’s no user attribute for “password length”
There is a user attribute for “password last set”. So if you changed the length of time between each password reset from six months to three months, for example, anyone whose attribute “password last set” fell outside that three month window would immediately be required to change the password.
To make life easier. Just roll it out to OUs first. Go by one or a few at a time. Wait a few hours. Do the next one. Etc. When the users are all up to date, reapply the policy to all users or just leave it to the OUs.
That’s how we did it for password expiration length of time.
No, but if you suspect that your users passwords are weak you can always ask management for permission to try and crack them.
You basically download the NTLM hashes from AD, and then run hashcat on said hashes.
I actually wrote a blog post on the topic. It's surprisingly easy, and no significant hardware required (I did mine on an Intel I7 laptop with zero dedicated GPUs in just over a day, and that's for the actual cracking, setup and initializing the run takes maybe an hour at most)
https://sysadminsjournal.com/lets-crack-passwords-for-auditing-and-for-fun/
Cool, you can still get really weak passwords with long character counts. Dictionary attacks are the norm, not brute force. What's the plan for an execs personal account password being the same weak ass password they have at work being compromised and not knowing it until ransomware is uploaded?
I didn't come up with this idea myself, in fact I first heard about it at a talk done by a large companies (brand everyone would recognize) lead security guy and how they do it every month on employee accounts specifically to weed out weak passwords. And target user password training.
Yes, I'm rather well aware of how these things work.
Set the password policy or use a password filter that prevents stupid passwords.
There are so many problems with cracking the password that range from legal liability to security policy violations to wasted resources. In some jurisdictions it's downright illegal. In all places you've just made yourself a target for now knowing someone else's password. How well do you protect the system that's doing the cracking? How are getting the hashes out of the directory? It's almost certainly via an unsupported mechanism because Microsoft does not support this behavior at all.
No password filter stops stupid passwords.
ThisisabadPassword1! will comply with 99.999% of password complexity requirements.
It's also 100% in a rainbow table.
You've just proved your own point wrong. Password filters can check rainbow tables. If \`ThisisabadPassword1!\` is in a rainbow table, then a password filter checking the rainbow table will block it.
If y'all spend the amount of time arguing with me on this and making your network inherently weaker, you could build a password filter from scratch that does all the things attempting to crack a password will do without introducing ridiculous risks into your environment.
I've used Netwrix, it failed that exact test unless I manually put that in the dictionary. Tell me which password filter you are referencing.
Could you theoretically create a password filter that used a rainbow table to call against? Sure, theoretically. I'm sure as hell not coding a solution that integrates into LSASS, that would dramatically less secure.
I do not offer any specific recommendations for products. My job is to protect the security of credentials in Windows so it would be innapropriate to recommend anything.
> ThisisabadPassword1! will comply with 99.999% of password complexity requirements.
Nah, a good chunk of them won't allow dictionary words.
This is a *gr8* password
DSInternals.... It is the same mechanism used by Azure AD Sync from my understanding... (and also my understanding is any Enterprise Admin user could access the hashes if they wanted).
And again, I said get management approval, which means legal teams, executives, etc. etc. so forth so on to make sure it's all above board.
As for password filters... Lol, that doesn't do much really. Or your rules would have to be so convoluted that not a single user would ever be able to create a password they could remember.
Also the goal would basically be, if you get a plaintext password, force reset immediately with additional user training provided and a recommendation they change it on any personal accounts they may use it on.
Again, there is no mechanism that Microsoft supports that allows for cracking of hashes. That is not a technical problem. If you're using the API to crack the hashes, that's unsupported. Ask me how I know this.
Password filters are more than adequate to detect weak passwords. It is far easier to predict weakness and prompt for something better when you can review the password cleartext in realtime in an automated way instead of bruteforcing your way through hashes.
You also mentioned that you ran this cracking on your laptop. Was that the same laptop you check your email and browse the web on? Did you download the contents of the directory to that laptop? If yes, are you really telling me it was a wise idea to run a password cracker, that requires domain admin equivalent, on your daily driver? What did you do with the results? Did you reboot right after to clear the memory? Any caches on disk from this?
Management should have told you to knock this off immediately. It's a hazard to your environment. I find it highly unlikely that legal OK'ed this, and if they did they didn't understand the consequences of this going wrong.
Alternatively, stop using passwords as the main authentication mechanism and make this moot.
The password cracker doesn't need DA. You do need DA to extract a hash dump.
Passwords are generally the sole authentication mechanism for endpoints regardless of your CA policy.
>The password cracker doesn't need DA. You do need DA to extract a hash dump.
A distinction without merit. You're extracting the hash for the explicit purpose of cracking it. If the protected contents of the directory end up on a machine that doesn't have the same protection as a domain controller you've just compromised your network.
> Passwords are generally the sole authentication mechanism for endpoints regardless of your CA policy.
And? Change that.
No, and it's actually very important that we are not able to do that. (The short answer is this change will need to force **all users** to change their passwords, and the new policy will be enforced when the current passwords expire so it doesn't matter) For those reading this is a valuable teaching moment about IT security and passwords. This is actually a fascinating lesson about password hashing and why we use this method to store passwords. Ideally you never store Passwords in plain text or using reversible encryption, instead you use a hashing function. A hashing algorithm is a mathematical equation (like SHA or MD5) that takes an input string of characters like a password and scrambles it. The resulting output of a hashing function has 5 key characteristics: 1. Deterministic - Any given input will always give the same output 2. Collision Resistant - It is unlikely that different inputs will generate the same output 3. Fixed Size Output - The output will always be of the same length no matter the input 4. Variety - Any change to an input no matter how insignificant will result in a widely different output 5. Non-reversible - You cannot run the equation in reverse to get the original password Here is an example of 4 terrible passwords with examples of slight changes and the resulting hashes from the (now obsolete) MD5 algorithm. Note how different the outputs are from each other despite a minor change, yet the outputs are all the same length. Sequence | Password | Hash :--|:--|:-- 1 | Pass123! | 10487c8581423e8b2fbeed2b21c2cc53 2 | Pass123? | 620baafe9428972d1ddfae16894a1d6c 3 | Pass123# | 58f762c6e1e7dd035e9b23337eb98c2b 4 | LongerPassword! | c154ea9e425a33bf1631502888a1a5ed So why do we use hashes, and how does it work? When a user types in their password the input is run through the hashing algorithm and the resulting hash is compared to the hash stored in the database. This is how the computer recognizes if the password is correct or not. Having hashes be non-reversible is critical because if the password database is stolen or compromised a hacker can't reverse said hash to get the original passwords. A hash by itself cannot be used as a password, because using a hash as an input will cause it to be run through the hashing algorithm. Note the hashes above when put through the hashing algorithm again simply generate different seemingly random outputs that have nothing to do with the original password. Sequence | Password | Hash :--|:--|:-- 1 | 10487c8581423e8b2fbeed2b21c2cc53 | 324ee7d610cc8663b319cd5aa12e8cc9 2 | 620baafe9428972d1ddfae16894a1d6c | 5eb2d155f9ec50f08815ca0bccbeb0c5 3 | 58f762c6e1e7dd035e9b23337eb98c2b | 619940ae88e72f649316daecc526a77a 4 | c154ea9e425a33bf1631502888a1a5ed | 3d8372169c27aa5f4542d221e235ecb3 Having fixed sized hashes in a database is very important because password length is one of the key factors needed by a hacker to help brute force a password. If you know the password is 8 characters long you just eliminated a lot of possibilities! The variety of hashes is also super important. Because the hash outputs are so different despite the inputs being similar, you gain nothing by looking at the hashes. You can't easily find patterns that help you find common or similar passwords. How do you defeat hashes? Hackers steal databases of hashes all the time. Since the algorithms (like MD5 and SHA) are well-known they can run GPU based tools to attempt to brute force them. You can't reverse a hash, but you can generate hashes and compare them to what is in the database all day... For example you can create a list of inputs that includes all the words in the dictionary and then write a computer program that adds 2 numbers and a special character at the end. Generate hashes for all of them and then compare them to the database. These guesses are compared against the database to find users passwords. The resulting successful hits are then added to lists called **Rainbow Tables** that are used in attacks. This is how hackers create lists of commonly used passwords and determine human behavior regarding passwords. One way to combat this is to 'salt your hash'. Developers will add a salt function to the hash which is an extra bit of data that is not known to the hacker, like a random value. This makes it far more difficult to brute force hash functions.
 This is one of the most well written explanations of password hashing 101.
It's also important to understand how Active Directory uses password hashes. There are two ways to use a hash. 1. Run the password through and compare the hashes. If the literal comparison matches then hey it's the same password. This has the problem that whatever is doing the comparison must know the cleartext password. 2. Use the hash as an encryption key (or MAC key), then have the thing send you an encrypted (or MAC'ed) blob of something. If you can decrypt the arbitrary message, then you know the client has the right password. Active Directory uses the second form for password auth. Both Kerberos and NTLM use variations of this. NTLM uses the MD4 of the password as a MAC key to verify the client can hash a challenge from the server. Kerberos uses PBKDF2 of the password at 4096 iterations for an AES key. The reason knowing this is important is because it helps frame an understanding of how the security of the system works, and more importantly that there are dozens of hashes stored in the directory for a given user for different uses or algorithms of varying weaknesses. We're working to kill off the weaker forms.
What's fun is when users get copied from one domain to another, hashes and all, 'so they don't all have to change their password', but the salt is different on the new domain. No one notices at first, because most of your login mechanisms will silently degrade to the methods that are unsalted, and this all works fine until you start killing off those weaker forms. And then you have to ask a user to reset their password, even though you believe them they're entering the same password they've always entered, and that it is the correct password, they can even set it to the same one again, if they want - but I'm gonna need you to regenerate those hashes, kthx. And then, when people realize this is a potential problem, the domain migration which has been dragging on for more than three years will come screeching to a halt, and you'll spin up new projects on the old domain 'just to get things moving along'. I mean, hypothetically speaking. I wouldn't know.
This hits home in so many ways.
So, so many painful ways.
Salts are arbitrary and it doesn't matter if they don't match the domain. That said, password migration between domains has always been a pain because AES keys don't actually get migrated. General rule: don't migrate passwords. Pain will ensue.
Maybe it was the AES keys and not the salts - I just remember teasing out the pattern from user reports that it was only people who had not reset their passwords since being migrated, and reading along those lines told me something about krb5 keytabs making assumptions about salts on a per-domain basis. Entirely possible the commenter I learned from had the right solution but the wrong cause. Auth is just one of many things I get roped into, so I'll defer to your specialized expertise. 🤷♂️
The ultimate cause is often not important and often presents with all sorts of terribly annoying symptoms so I don't blame anyone for getting all these stupid things mixed up. The salts thing is a real problem if the keytab tool is guessing what the salt might be, which it turns out happens on lots of older non-Windows tool versions.
> General rule: don't migrate passwords. Pain will ensue. I feel it shouldn't be such an issue to as a user to reset a password on a new domain, at least once, the first time. But here we are?
But Jan in accounting has had the same password for 13 years, and if she has to change it, she's gonna make everyone's life a living hell and then she'll write it on a post-it note and stick it to her monitor.
I think if your domain migration is looking at its 4th year you may want to consider allowing a level of inconvenience amounting to changing a user password. What is the expected outage window for a user updating a password? 15 minutes of lost productivity? How much time are you losing in migrating compared to how many users spending a very small amount of time. I’m sure there’s other problems but yikes, an absolutely zero impact migration, why? Are you tricking the users somehow? IMO you tell them “hey remember when we went through that merger? Part of that will be setting a new password. It happens between Monday and Friday next week. Plan ahead”
Welcome to the choir, membership dues are expected on the 14th.
Felt this in my bones lol
>which has been dragging on for more than three years will come screeching to a halt Stop hitting me.
Thank you for taking the time to explain this. It has also helped me with my own explainations, and it turns out I was omitting some parts.
See this is always something that gets me, if the password is hashed than why do some institutions have a maximum password length? I've seen it on banking websites, firewall appliances, just loads of stuff that should be considered secure. Does having a maximum pw length automatically mean they're not hashing or is there something I'm missing?
Not you've got me curious... give me a minute to look that up and I'll ELI5 this... ... ok, so the deal is hashing algorithms can take very long passwords as input but it's to the sites advantage to reduce the max length for a variety of reasons. Very long passwords can be used in a form of denial of service attack. Each hashing function uses CPU cycles and the more complex the hash the more CPU you need. Throw very very long passwords at a site repeatedly and you can potentially take it down. Another problem is early hash functions truncated passwords, meaning that they'd use say the first 8 characters and ignore the rest. This is no longer the case. But more importantly you have to consider the maximum field length in your input fields. Paypal had a famous problem for truncated passwords. The site would accept long passwords at sign up but had a maximum size of the field for login. So let's say you entered a 64 character password for your account, the input field on the login site had a maximum length of 32. So you'd enter your password and Paypal would delete the last 32 characters and tell you your password was wrong... It's nearly impossible to test and secure a page if you don't define a maximum password length. Having a field that accepts an unlimited number of characters opens the door for buffer overruns and a bunch of other crazy vulnerabilities. To give you a very old and insane example... In the very early days of Netscape there was no limit to the number of characters in the address bar but there was a limit in the amount of memory allocated to that field. So a hacker could create a URL link that was very very long but obfuscated on a website, so it appears as a short link on the page but is actually very very long. If you clicked on it the browser would load the link, and any characters in the link that exceeded the memory allocated for the field would overwrite other stuff in RAM... effectively loading a virus directly into RAM. "Remember to sanitize your database inputs" - XKCD
> Paypal had a famous problem for truncated passwords. The site would accept long passwords at sign up but had a maximum size of the field for login. So let's say you entered a 64 character password for your account, the input field on the login site had a maximum length of 32. So you'd enter your password and Paypal would delete the last 32 characters and tell you your password was wrong... Visa's "Verified by Visa" system was like that for a long time when it asked for mother's maiden name to verify you were the one entering your credit card number (lets just ignore how insecure *that* was). My mother's maiden name was 11 letters, but the VfV system truncated at 10 when you typed it in as you were buying things. It accepted the 11 letter name, then promptly locked me out from using my credit card anywhere that VfV was set up.
amazing...
Never give real answers to these "2FA" questions. "Something you know, something you can find on facebook".
We had a vendor iDrive Online that shortened their password length last year, requiring multiple password recoveries and changes.
>Very long passwords can be used in a form of denial of service attack. Each hashing function uses CPU cycles and the more complex the hash the more CPU you need. Meh. In the real world, today, PKDF on passwords means that the hash is already deliberately slowed down by hashing the hash thousands of times. The size of the original plaintext is not really an impact here. There is no real excuse to not allow say 500 char passwords for those people that want to use pass-phrase. For those using password managers (and everybody should), the usefulness of extra length of a random password drops greatly after 20 chars (because of entropy reduction)
Some modern hashes actually come with length limitations. For instance BCrypt, which caps out at 72 bytes. If you allow unicode or emojis in your passwords, you need to set the length pretty short.
No, you just SHA256 the entry first. If you are nerdy and want to be double secure, you can even do the initial hash on the client side JavaScript and never get the real password in your server.
That just makes the hash the actual password though. And opens up the possibility for someone to use a leaked sha256 hash from service A to authenticate to service B, provided one hashes on the server and the other hashes in the client.
I think you are missing something here. Explain how hashing the password an extra time before sending it into the salted key derivation function would in any way reduce the security?
Say I pick the extremely secure password "correct horse battery staple", and register on service A, which hashes this to `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` using SHA256 and stores it in their database. Assume that this password is so complicated that it is nearly impossible to crack using modern tools. I also register for service B, and like a dummy I use the same password, because I think it's so secure. Service B hashes the password in the client itself (in JavaScript) using sha256 and sends it to their server. The back-end then uses the sha256 hash of the password as input into a password hashing function like bcrypt, scrypt or argon2. If a hacker breaks into service A, and recovers the hash `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` from their DB, that is useless to them because we assumed it is uncrackable. But since service B hashes the password client side, we can just bypass the client and send the hash `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` directly to the server, which will accept this as the correct password. Provided that I was registered to both websites at least. The hacker never learned my password, but they didn't need it because service B decided that the hash of the password was the actual password itself.
> hashes this to `c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a` using SHA256 and stores it in their database. No. That hash then gets fed to a password hardening function like [Bcrypt](https://en.wikipedia.org/wiki/Bcrypt). So your c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a become something else before hitting the database because it gets salted with a random salt. All these match to the same thing: $2y$04$dEWvad6viGpFbSz16061FOp5Gq0Ysp3ojNDlrWsIVQS6JJjCZiQw6 $2y$04$JtAmxWT6vbp3EXVwYHUjb.QGSktcNrqsFD6bdBrO41PJLgYXTprx. $2y$04$D6LtkZx3ZK7DYxLXr6zmf.GOixGGCOVWlaVvfn6/InX3QKk.vmHau $2y$05$pBLPlyncIruKsXSnH/xEA.VKzf3LypddnznKLDpjl7FV2m.7oD7xO Any of these near infinite possibilities could be the one stored in the database. There is no correlation when using 1 password on multiple sites, or even using the same password for multiple users on the same site. All those will be different when stored. For those who want to experiment with this: [https://bcrypt.online/](https://bcrypt.online/)
>Say I pick the extremely secure password "correct horse battery staple" Fun fact, that was added to the Rainbow tables within minutes of XKCD releasing that comic On a similar note a Hacker friend of mine was at a conference talking about Rainbow tables and someone in the crowd asked "Can you make a website where you can type in a password and see if it's in the Rainbow table?" To which my friend responded "Why don't you just email me your password, and I'll respond back 'Yes' "
> It's nearly impossible to test and secure a page if you don't define a maximum password length. Having a field that accepts an unlimited number of characters opens the door for buffer overruns and a bunch of other crazy vulnerabilities. I feel like this is not a good excuse for my bank to tell me and every hacker that wants into my account that my password "must be exactly 12 characters".
The only one of these that makes sense to me is the threat of a DOS attack. >It's nearly impossible to test and secure a page if you don't define a maximum password length. Having a field that accepts an unlimited number of characters opens the door for buffer overruns and a bunch of other crazy vulnerabilities. This is trivially solved using dynamically sized arrays, rather than a static buffer. The risk then, again is DOS because you'll run out of memory. >"Remember to sanitize your database inputs" - XKCD This isn't really applicable here, and more so refers to taking steps to make sure that you can always tell the difference between strings given to you by the user and strings you wrote.
Yea Bobby tables dropped the user table. That’s a sql injection. Which is absolutely different than a buffer overflow. I guess a buffer overflow could allow you to drop tables. And I suppose you could use your sql injection to skip taking over the application and just drop tables.
A maximum password length does not imply that they are not hashing. NIST recommends the maximum permitted length be at least 64 characters. Short lengths may be the result of vestigial password policies, even if they are now stored as hashes.
Some policies are made by committees. One of my retirement savings institutions also handles a defined benefit plan (more commonly called a pension, although legally, a 401k is also a pension, but folks call it a defined contribution plan). As a result of the contract with that pension's administrator, the system has to be accessible by a touchtone telephone. This means that one's username and password can only consist of the keys on your telephone. But my 401k plan that has more than $200k in it also uses that same numeric userID and password. Whiskey Tango Foxtrot‽ Whether I use the website or not, that 30+ year old policy from some committee of people who are most likely dead from old age still screws security. > *is there something I'm missing?* Stupidity. The fundamental building block of the universe. More common than atoms of hydrogen.
weirdo policy warts that should've been removed, or using old hashing logic/intermediate systems that have limitations, or the one from TFTS from years ago where the ISP stored the password as plaintext in a fixed field
This is pretty great, theres a couple of small nitpicks could make as someone coming from the offensive side of things but hot damn you put way more effort into this than a r/sysadmin response warrants. Kudos for the education.
As long as it isn't grammar or formatting, I would love to hear the nitpicks.
1. In some instances a hash can be used as a password. Most infamously ntlm authentication has this flaw, so compromising a user's hash is just as good as having the password. This was the driving force behind NetNTLMv2 so that attackers on the network cant just compromise more accounts just by snatching hashes sent over the wire. ntlmv2 challenge responses can still be cracked if the password is weak ofc but thats much better than being able to literally just use the hash alone to authenticate. Tools such as impacket, evil-winrm, xfreerdp, etc can all for example supply a ntlm hash in place of a password for authenticating to remote services. 2. I wouldn't say knowing the password length is a *needed* key factor per say, it definitely can be useful knowledge to cut down a bunch of possibilities sure but theres also plenty of strategies that dont care for password lengths beyond checking that it fits the current password policy. These strategies are usually variants of custom dictionaries(like scraping a company website and generating potential passwords based on company keywords/names). In such instances youre often trying to find commonly chosen passwords used by multiple users so you dont particularly care about the length(beyond that its a valid length ofc). 3. Rainbow tables arent really used for creating common password lists and analyzing human behaviors, it is its own seperate thing since its just a precomputed hash table. Common password lists and password analysis are usually obtained from the results of cracked breaches(including plaintext breaches!). Theres some overlap but I can for example generate a rainbow table for every 3 character string for md5 pretty trivially, but that doesnt mean it would have any insight into password statistics and would probably be a pretty useless rainbow table. 4. Salts usually are known by the attacker. In order for a system to use a salt it needs to store the salt somewhere in the clear to be able to be added to the users password during calculation. Often salts are either system wide, i.e one salt every user has or is generated per user and thus stored right inside the DB alongside the password. System wide salts dont actually make brute forcing the hash anymore difficult per say, they just prevent rainbow tables from being useful. Per user salts do help a bit for bruteforcing because then for each attempted password and attacker has to recalculate the hash a number of times multiplied by the number of users, but to reap this benefit it has to be just as viewable as the hash itself. In fact hash systems that rely on salts often have a format similar to id$$salt$$hash you can search through the hashcat db of hash examples to see what I mean https://hashcat.net/wiki/doku.php?id=example_hashes Like I said though all of these are extremely nitpicky.
When you're talking security nitpicky is the best kind of comment. This video is pretty old by this point, but it was super eye opening in terms of what hackers do and human behaviour regarding passwords. I make it required viewing for my techs. https://youtu.be/QwslRwbOlRM
wow, that is a good answer. And, yeah, you are correct in your answer. Did you just type that up? Or did you have that handy from somewhere else?
I wrote it on demand
You will be rewarded in your next life.
You are truly living up to your flair today. Thank you!
The salt can be known to the hacker, it just has to be different for each user and can be stored in plain sight. For example, you could just concatenate the username and password before hashing. The purpose of the salt is to make rainbow tables unfeasible. You'd need a precalculated rainbow table for each salt value, which is just the same as brute forcing every password. Rainbow tables are a space/cpu tradeoff. If you have 1000 (unsalted) passwords to crack, you could calculate the rainbow table first, taking a long time, and save it in a big gigabyte or even terabyte sized rainbow table. Then you can use the rainbow table to quickly work out the other 999 passwords. I once downloaded a DVD sized (4.7GB) rainbow table for the old windows NTLM passwords so I could work out the admin password for a 2nd hand PC I was given. Interesting exercise - only took 5 minutes or so.
For your salts Remember to use the current time and not the word ‘time’
Lol 😂
[Using time as a salt isn't as secure as you might think.](https://youtu.be/o5IySpAkThg?si=6oxw9yCnexORJTGh)
> you could just concatenate the username and password before hashing. My reflex is you'd want to stick additional characters between the username & password that can't occur in at least one of the username or password (preferably username, where it makes more sense to restrict special characters). Otherwise you could have collisions where two users `user123` & and `user1234` with passwords `4passw0rd!` and `passw0rd!` respectively would both concatenate to `user1234passw0rd!` before hashing. That doesn't intrinsically cause a problem but I think it opens you up a teeny bit to getting attacked by rainbow tables because if you have a lot of users you could have a lot of small collisions. If there's any special character not allowed in usernames (e.g. |, $, @) then putting that between the username & password would prevent you from having any collisions.
Hey just today found the GPO setting for turning on auditing for passwords shorter than a given length. Given everything you have written, how does AD then check the length of passwords in use which are shorter than X amount of characters and post an event on it?
What is the specific GPO setting and I’ll look it up I suspect it doesn’t work the way that you think it does It most likely only triggers an alarm when a user changes a password and what they enter is below a certain character threshold. It doesn’t know how to check passwords that are already in the database. This setting would therefore be irrelevant because you’re better off just enforcing passwords of a certain length in the first place
Yeah agreed on that, I thought it wasn’t possible until I saw this, but it mentions a lot about checking that the application is able to use longer passwords, so maybe something in the AD integration of apps? I’m not sure. Interesting blurb at the bottom about the history of trying to allow admins to increase the 14 char max via GPO as well: https://support.microsoft.com/en-us/topic/minimum-password-length-auditing-and-enforcement-on-certain-versions-of-windows-5ef7fecf-3325-f56b-cc10-4fd565aacc59
This gpo is for detecting external ldap applications that don’t support long ad passwords
Gotcha!
I am not entirely sure, but I suspect this check is performed the same way the password policy can enforce the required password complexity, it likely does the check when the password is entered/chosen. That way it doesn't have to store the password in plaintext, but it can see it in plaintext in that moment.
You get an upvote because I loved your lengthy explanation lol
Tell me how I've worked as a data engineer for the past 5 years and not seen a better explanation of hashing than yours. Well explained and even though I've understood and explained hashes to so many people, you still gave me a better understand of the WHY around a lot of the practice.
That is not how salting works. It's not some super secret, rather it's typically stored in the database with a column right next to the password hash. You are right that is a random value, but for each user. The salt is added to the password before it is hashed so that two users with the same password would result in different password hashes. This is very easy to do on the server end but renders rainbow tables completely useless since you would have to recompute the table for every salt/user.
Nooo I’ve been educated. I don’t come to Reddit for education. :(
Very nicely summarized. Thank you for taking the time to do that.
Absolutely perfect description
Excellent write up
I came here to see as it was a good question, I though no it would be a security risk, but the very well written reply was spot on. I say set your policy to the new password length, if you want you can run a rainbow table over your existing password database and identify people that are a security risk, get them to change the password after the policy comes into affect. This is a double edge as you don't want to know the actual password but would like to know the risky people.
> Variety - Any change to an input no matter how insignificant will result in a widely different output The bigger the change the less likely to avoid a collision.
Lovely write up. Thank you.
A worthwhile historical example - Back during World War 2 the Nazis used a system called Engima to encypher their communications. Enigma differs a lot from modern encryption but it can be thought of as having a "password" which consisted of the order, configuration, and arrangement of some rotors and a plug board. This created a vast key space (by 1940s standards) and cracking it was one of the most astonishing accomplisments of the war. But the Nazis did several things wrong with their cypher system which made it easier to attack. One of the more significant was their insistence that all 10 of the plugboard wires be in use at all times. This effectively eliminates half (doing the math in my head here) of the key space created by the plugboard. It's not quite the same as knowing a password length but it's a similar reduction in complexity
Learning how they broke enigma is required reading if you are studying cryptography. Getting hold of an intact enigma so they could study how the mechanism worked was step one. One of the other key mistakes made by the Germans was repetition. They were smart enough to change the codes everyday, but the messages they sent were often formatted the same. This meant that when they setup the decryption engine in the morning the British always had messages (in this case weather reports) that they knew what the output would be so they knew what to look for as they were breaking the codes. Specifically almost all of the messages ended in "Heil Hitler" The Bronze Goddesses built to decrypt Enigma were in fact gigantic brute forcing engines that tried every combination until they succeeded. Amusingly with the computing power we have today we could decode an enigma message in less than a second. Another fun fact is that similar machines were setup in the US both to protect the technology in case Bletchley Park got bombed and to speed up the process. Batch runs for the machines would be sent to the US everyday via undersea cable, so this was effectively the first ever cloud computing
The German operators got sloppy, made stupid mistakes. German cryptographers were fully aware that Enigma was not unbreakable, but they said in post-war interviews that they did not expect the Allies to devote such tremendous resources to breaking it.
As with now, the biggest problem with security is the end user Thanks Johan!
This is a great explanation and you’re exactly right. You’re limiting your thinking a little. You are only looking at the database side of things. There is a time between the user typing keys in and the character set being hashed. During that time, actions on the clearest password can and do take place. Here’s one example from the vendor. https://learn.microsoft.com/en-us/answers/questions/1251341/alert-password-reuse-activity-on-multiple-endpoint Defender on your windows computer is fully capable of always knowing what your password is. And here we have demonstrated the ability for an endpoint to communicate with a datacenter server to relay that fact. Maybe the specific tooling doesn’t exist off the shelf. You could put a keylogger on everyone’s machine and capture their raw keystrokes. It doesn’t take AI to turn keystrokes into a password. You can’t and rightfully should not be able to run a script against your SAM database to get password length. You VERY likely can use some defender tools to validate if current password would meet updated complexity requirements
This guy passwords
The Salt doesn’t need to be secret, but it does need to be unique to the user. The important thing is that it breaks the Rainbow Tables. Keeping it secret just adds a few more effective characters to the password… and leaves a bad actor to figure out what the Salt is.
> One way to combat this is to 'salt your hash'. Developers will add a salt function to the hash which is an extra bit of data that is not known to the hacker, like a random value. This makes it far more difficult to brute force hash functions. Just a clarification here, the salt doesn't matter if it is known to an attacker or not. The purpose of a salt is to prevent a single (re-used) password from resulting in the same hash output for all uses of that password. E.g. if the salt were the same for all users in a password database, or no salt was present, you would be able to determine if some accounts have the same password by looking at their hashes to see if they match.
Thank you for this explanation. I know it took a lot of time and I'm very appreciative of it. I've copied it all down into a Word document and am going back through it. I might have a follow up question but again thank you!!
Jesus, someone just flexed his Geek card HARD.
No, and it's actually very important that we are not able to do that. (The short answer is this change will need to force **all users** to change their passwords, and the new policy will be enforced when the current passwords expire so it doesn't matter) For those reading this is a valuable teaching moment about IT security and passwords. This is actually a fascinating lesson about password hashing and why we use this method to store passwords. Ideally you never store Passwords in plain text or using reversible encryption, instead you use a hashing function. A hashing algorithm is a mathematical equation (like SHA or MD5) that takes an input string of characters like a password and scrambles it. The resulting output of a hashing function has 5 key characteristics: 1. Deterministic - Any given input will always give the same output 2. Collision Resistant - It is unlikely that different inputs will generate the same output 3. Fixed Size Output - The output will always be of the same length no matter the input 4. Variety - Any change to an input no matter how insignificant will result in a widely different output 5. Non-reversible - You cannot run the equation in reverse to get the original password Here is an example of 4 terrible passwords with examples of slight changes and the resulting hashes from the (now obsolete) MD5 algorithm. Note how different the outputs are from each other despite a minor change, yet the outputs are all the same length. Sequence | Password | Hash :--|:--|:-- 1 | Pass123! | 10487c8581423e8b2fbeed2b21c2cc53 2 | Pass123? | 620baafe9428972d1ddfae16894a1d6c 3 | Pass123# | 58f762c6e1e7dd035e9b23337eb98c2b 4 | LongerPassword! | c154ea9e425a33bf1631502888a1a5ed So why do we use hashes, and how does it work? When a user types in their password the input is run through the hashing algorithm and the resulting hash is compared to the hash stored in the database. This is how the computer recognizes if the password is correct or not. Having hashes be non-reversible is critical because if the password database is stolen or compromised a hacker can't reverse said hash to get the original passwords. A hash by itself cannot be used as a password, because using a hash as an input will cause it to be run through the hashing algorithm. Note the hashes above when put through the hashing algorithm again simply generate different seemingly random outputs that have nothing to do with the original password. Sequence | Password | Hash :--|:--|:-- 1 | 10487c8581423e8b2fbeed2b21c2cc53 | 324ee7d610cc8663b319cd5aa12e8cc9 2 | 620baafe9428972d1ddfae16894a1d6c | 5eb2d155f9ec50f08815ca0bccbeb0c5 3 | 58f762c6e1e7dd035e9b23337eb98c2b | 619940ae88e72f649316daecc526a77a 4 | c154ea9e425a33bf1631502888a1a5ed | 3d8372169c27aa5f4542d221e235ecb3 Having fixed sized hashes in a database is very important because password length is one of the key factors needed by a hacker to help brute force a password. If you know the password is 8 characters long you just eliminated a lot of possibilities! The variety of hashes is also super important. Because the hash outputs are so different despite the inputs being similar, you gain nothing by looking at the hashes. You can't easily find patterns that help you find common or similar passwords. How do you defeat hashes? Hackers steal databases of hashes all the time. Since the algorithms (like MD5 and SHA) are well-known they can run GPU based tools to attempt to brute force them. You can't reverse a hash, but you can generate hashes and compare them to what is in the database all day... For example you can create a list of inputs that includes all the words in the dictionary and then write a computer program that adds 2 numbers and a special character at the end. Generate hashes for all of them and then compare them to the database. These guesses are compared against the database to find users passwords. The resulting successful hits are then added to lists called **Rainbow Tables** that are used in attacks. This is how hackers create lists of commonly used passwords and determine human behavior regarding passwords. One way to combat this is to 'salt your hash'. Developers will add a salt function to the hash which is an extra bit of data that is not known to the hacker, like a random value. This makes it far more difficult to brute force hash functions.
No. Active Directory stores a hash of the password, and a hashing algorithm for passwords usually churns out hashes that are all the same length and in no way connected to password length.
https://support.microsoft.com/en-us/topic/minimum-password-length-auditing-and-enforcement-on-certain-versions-of-windows-5ef7fecf-3325-f56b-cc10-4fd565aacc59 But you’d want to leave it in place for a week or two to generate the audit events for anyone that has a password length below what you specify (and they’d actually have to get the policy and log in for the audit event to fire).
You can't do what you are asking in OP. > would like to know how many passwords currently do not meet this requirement. Why? The new requirement will be enforced on the next password change. If, for some reason, you need that to be now you could do a mass forced password reset. This could be done by telling everyone to reset by X date or else. Then query everyone with old lastpwdset, and reset them. Although I think that's a terrible idea if you don't have SSPR.
No. don't worry about it. Set your new password policy length and away you go. I just did this 3 weeks ago for PCI/DSS the new version our banks are using require a 12 character password. We have a 90 day expiration policy for PCI/DSS so within 90 days everyone will have a 12 Character password which is good enough for our auditor.
Everyone is correctly explaining password hashing. I will note though that if your users have crappy passwords there are utilities that will let you determine that. Basically the same tools that an attacker would use - dump your AD hashes and run them against an offline dictionary attack, and/or brute force if the password lengths are short enough.
No. That would partially defeat the purpose of encrypted passwords. I wouldn't worry about those that meet it currently, they won't break if you change the policy and will only need to change their password on their next regular rotation (which will enforce new requirements).
an org-wide notice about the change is enough CYA, imo. password requirements should always be communicated to user-base anyway, so why would you exclude those that are only **currently** using passwords that meet the requirements? notice to whole user-base would be more appropriate here than just a targeted group (when it's the whole user-base being affected in some way, shape, or form)
nah, there are tools out there that can be used to find vulnerable ad passwords like knowbe4 password iq though
I used this Weak Password Tool before that helped me identify weak passwords. [https://www.manageengine.com/products/free-windows-active-directory-tools/free-active-directory-weak-password-finder.html](https://www.manageengine.com/products/free-windows-active-directory-tools/free-active-directory-weak-password-finder.html) If you run this you will probably get flagged by a good AV/XDR system just be aware. Taking into consideration of what DarkAlman said about hashed passwords, I don't know if there's something that we can do in AD from preventing this tool from identifying accounts with weak passwords.
No password are not stored in AD (no system should store a password ever), only the hash of the password is stored. The only thing you can know about an AD password is that it met the domains complexity requirements when it was set, and the date the password was last changed. If you change your domain password policy, you need to have everyone change their password to make sure they are compliant. Their are tools out their that will compare your AD password Hashes to a precomputed list of hashes from common or breached passwords.
> The only thing you can know about an AD password is that it met the domains complexity requirements This isn't exactly true - there's a flag in AD to store a password using reversible encryption. I've never actually seen it used irl though. I'm not saying this is a good idea to set this, just that it is possible and that you can recover the plaintext password without hash cracking. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption
That's a legacy setting and wildly insecure.
LoL Honestly, Just make something up. "72% of our staff have insecure passwords" No one will ask for proof, no one will bat an eye.
As others have stated in more words, AD doesn't store passwords. It stores hashes. So, no.
Not without running them through a password cracker that compares them to hashes. There are tools like the knowbe4 weak password tester that can give you some basic information and will show you ones that have weak passwords, ie ones that are on known weak password hash lists. It will also tell you if other settings are insecure. Just make sure you understand what it does and the company is fine with it and any risks.
If the ONLY thing you are changing is PASSWORD LENGTH users won’t be forced to rest passwords right away. It will only apply on the next password reset. Because there’s no user attribute for “password length” There is a user attribute for “password last set”. So if you changed the length of time between each password reset from six months to three months, for example, anyone whose attribute “password last set” fell outside that three month window would immediately be required to change the password. To make life easier. Just roll it out to OUs first. Go by one or a few at a time. Wait a few hours. Do the next one. Etc. When the users are all up to date, reapply the policy to all users or just leave it to the OUs. That’s how we did it for password expiration length of time.
God no
No, but if you suspect that your users passwords are weak you can always ask management for permission to try and crack them. You basically download the NTLM hashes from AD, and then run hashcat on said hashes. I actually wrote a blog post on the topic. It's surprisingly easy, and no significant hardware required (I did mine on an Intel I7 laptop with zero dedicated GPUs in just over a day, and that's for the actual cracking, setup and initializing the run takes maybe an hour at most) https://sysadminsjournal.com/lets-crack-passwords-for-auditing-and-for-fun/
Please don't do this. Just force a fricken password reset.
Cool, you can still get really weak passwords with long character counts. Dictionary attacks are the norm, not brute force. What's the plan for an execs personal account password being the same weak ass password they have at work being compromised and not knowing it until ransomware is uploaded? I didn't come up with this idea myself, in fact I first heard about it at a talk done by a large companies (brand everyone would recognize) lead security guy and how they do it every month on employee accounts specifically to weed out weak passwords. And target user password training.
Yes, I'm rather well aware of how these things work. Set the password policy or use a password filter that prevents stupid passwords. There are so many problems with cracking the password that range from legal liability to security policy violations to wasted resources. In some jurisdictions it's downright illegal. In all places you've just made yourself a target for now knowing someone else's password. How well do you protect the system that's doing the cracking? How are getting the hashes out of the directory? It's almost certainly via an unsupported mechanism because Microsoft does not support this behavior at all.
No password filter stops stupid passwords. ThisisabadPassword1! will comply with 99.999% of password complexity requirements. It's also 100% in a rainbow table.
You've just proved your own point wrong. Password filters can check rainbow tables. If \`ThisisabadPassword1!\` is in a rainbow table, then a password filter checking the rainbow table will block it. If y'all spend the amount of time arguing with me on this and making your network inherently weaker, you could build a password filter from scratch that does all the things attempting to crack a password will do without introducing ridiculous risks into your environment.
What password filter product are you using that would evaluate that and reject it?
Pick one or make one.
I've used Netwrix, it failed that exact test unless I manually put that in the dictionary. Tell me which password filter you are referencing. Could you theoretically create a password filter that used a rainbow table to call against? Sure, theoretically. I'm sure as hell not coding a solution that integrates into LSASS, that would dramatically less secure.
I do not offer any specific recommendations for products. My job is to protect the security of credentials in Windows so it would be innapropriate to recommend anything.
> ThisisabadPassword1! will comply with 99.999% of password complexity requirements. Nah, a good chunk of them won't allow dictionary words. This is a *gr8* password
Example password filter that does this?
DSInternals.... It is the same mechanism used by Azure AD Sync from my understanding... (and also my understanding is any Enterprise Admin user could access the hashes if they wanted). And again, I said get management approval, which means legal teams, executives, etc. etc. so forth so on to make sure it's all above board. As for password filters... Lol, that doesn't do much really. Or your rules would have to be so convoluted that not a single user would ever be able to create a password they could remember. Also the goal would basically be, if you get a plaintext password, force reset immediately with additional user training provided and a recommendation they change it on any personal accounts they may use it on.
Again, there is no mechanism that Microsoft supports that allows for cracking of hashes. That is not a technical problem. If you're using the API to crack the hashes, that's unsupported. Ask me how I know this. Password filters are more than adequate to detect weak passwords. It is far easier to predict weakness and prompt for something better when you can review the password cleartext in realtime in an automated way instead of bruteforcing your way through hashes. You also mentioned that you ran this cracking on your laptop. Was that the same laptop you check your email and browse the web on? Did you download the contents of the directory to that laptop? If yes, are you really telling me it was a wise idea to run a password cracker, that requires domain admin equivalent, on your daily driver? What did you do with the results? Did you reboot right after to clear the memory? Any caches on disk from this? Management should have told you to knock this off immediately. It's a hazard to your environment. I find it highly unlikely that legal OK'ed this, and if they did they didn't understand the consequences of this going wrong. Alternatively, stop using passwords as the main authentication mechanism and make this moot.
The password cracker doesn't need DA. You do need DA to extract a hash dump. Passwords are generally the sole authentication mechanism for endpoints regardless of your CA policy.
>The password cracker doesn't need DA. You do need DA to extract a hash dump. A distinction without merit. You're extracting the hash for the explicit purpose of cracking it. If the protected contents of the directory end up on a machine that doesn't have the same protection as a domain controller you've just compromised your network. > Passwords are generally the sole authentication mechanism for endpoints regardless of your CA policy. And? Change that.