How does IT audit password contents?

[AbydosOne]

Lately, my corporate IT has taken it upon itself to "audit" our passwords and declare any as "being vulnerable to modern hacking techniques" (i.e. contain personally relevant strings, like, say, address number) needing to be changed.

 

I know exactly why my password doesn't pass muster (though work is the only place I use it, so IMO it's not that vulnerable, I'm just stubborn and our IT is notoriously not-competent), I'm just a little incensed that somehow IT can view passwords in plaintext!?

 

Does Active Directory not store hashed passwords? Is there a hashing algorithm that can extract substrings for comparison? ¹  Or is IT really so hypocritical as to actually store/unencrypt passwords in plaintext somewhere and then tell *us* to be more secure?

 

1 = The only way I could think this would be possible would be that the "hash" of the password would actually be a collection of hashes of various substrings when it's made, but I can't find an evidence that this is true.

[Agall]

14 minutes ago, AbydosOne said:

Lately, my corporate IT has taken it upon itself to "audit" our passwords and declare any as "being vulnerable to modern hacking techniques" (i.e. contain personally relevant strings, like, say, address number) needing to be changed.

 

I know exactly why my password doesn't pass muster (though work is the only place I use it, so IMO it's not that vulnerable, I'm just stubborn and our IT is notoriously not-competent), I'm just a little incensed that somehow IT can view passwords in plaintext!?

 

Does Active Directory not store hashed passwords? Is there a hashing algorithm that can extract substrings for comparison? ¹  Or is IT really so hypocritical as to actually store/unencrypt passwords in plaintext somewhere and then tell *us* to be more secure?

 

1 = The only way I could think this would be possible would be that the "hash" of the password would actually be a collection of hashes of various substrings when it's made, but I can't find an evidence that this is true.

I'm going to guess they're just going to change password complexity/history requirements and force a password change on to every account. If they're notoriously incompetent, then they're likely bloviating to oversell their capabilities. The guy I replaced used to do that and would lie to employees to force compliance with extremely aggressive security policies. 

 

I'm personally unaware of any way to see passwords in plaintext in Microsoft AD, but I'll be curious to see if anyone does  

[OhYou_]

No they do not have to store the password in cleartext, they can just analyze it at any time you enter it for compliance.
Some rare cases, the password is analyzed at creation and information about it is stored in cleartext, this would look like contains: x amount letters, numbers, no special characters, ect ect.

[manikyath]

auditing passwords.. that's a new one. in all my 6 years of IT i've never heard a manager say something that stupid. 

 

also, if you have not changed your password since they implemented that strategy, they're doing something VERY fishy to figure out your password.. and it's probably best to just play along with their silly games so they cant try to blame you when things inevitably go down the pooper.

[dilpickle]

12 minutes ago, OhYou_ said:

No they do not have to store the password in cleartext, they can just analyze it at any time you enter it for compliance.

Yes this is how most websites do it. Its being checked locally by your browser.

[AbydosOne]

9 minutes ago, manikyath said:

also, if you have not changed your password since they implemented that strategy, they're doing something VERY fishy to figure out your password.

Yeah, this was the part that stands out. I haven't changed it since last June, and it didn't flag it then, so somehow they're accessing it in plaintext after the fact.

 

I emailed them back, just to see if someone would reach out to me about it (I doubt they will).

[Agall]

1 minute ago, AbydosOne said:

Yeah, this was the part that stands out. I haven't changed it since last June, and it didn't flag it then, so somehow they're accessing it in plaintext after the fact.

 

I emailed them back, just to see if someone would reach out to me about it (I doubt they will).

Does your company have a 3rd party MFA software to log into your machine?

 

12 minutes ago, manikyath said:

auditing passwords.. that's a new one. in all my 6 years of IT i've never heard a manager say something that stupid. 

 

also, if you have not changed your password since they implemented that strategy, they're doing something VERY fishy to figure out your password.. and it's probably best to just play along with their silly games so they cant try to blame you when things inevitably go down the pooper.

 

I imagine some of the 3rd party MFA tools would allow this, even with Microsoft AD? Effectively a keylogger to validate compliance before it reaches the DC?

[AbydosOne]

3 minutes ago, Agall said:

Does your company have a 3rd party MFA software to log into your machine?

Nothing that runs before login, that I'm aware of. Obviously they have third-party permissions management, but I don't think it's low-level enough to get into the login process.

 

4 minutes ago, Agall said:

Effectively a keylogger to validate compliance before it reaches the DC?

Well that's not sketchy at all... maybe I should stop writing posts from my work computer lol

[OhYou_]

4 minutes ago, AbydosOne said:

Yeah, this was the part that stands out. I haven't changed it since last June, and it didn't flag it then, so somehow they're accessing it in plaintext after the fact.

 

I emailed them back, just to see if someone would reach out to me about it (I doubt they will).

yeah but surely youve had to enter it since last june.
every time you enter it, it is encrypted and sent to the server where its decrypted and verified so that you can log in. the server can just check it at any of those times and notify IT for incompliance, or more likely notify you automatically and not let you log in till you  fix it.
this is not new stuff, it is done everywhere

[AbydosOne]

3 minutes ago, OhYou_ said:

sent to the server where its decrypted and verified

My understanding of password validation is that they compare the "encrypted"/hashed values. Passwords shouldn't ever be "decrypted", I'm pretty sure, especially if the "encryption" is a hash algorithm that is computationally very expensive to reverse.

[OhYou_]

1 minute ago, AbydosOne said:

My understanding of password validation is that they compare the "encrypted"/hashed values. Passwords shouldn't ever be "decrypted", I'm pretty sure, especially if the "encryption" is a hash algorithm that is computationally very expensive to reverse.

your password is encrypted on your pc and sent to the server where it is decrypted back into cleartext. THEN it is hashed and compared to the stored hash.
it cannot be hashed on your pc because your pc is not the one verifying the password is the correct one

 

[Agall]

17 minutes ago, AbydosOne said:

Nothing that runs before login, that I'm aware of. Obviously they have third-party permissions management, but I don't think it's low-level enough to get into the login process.

 

Well that's not sketchy at all... maybe I should stop writing posts from my work computer lol

Everyone likes the idea of MFA on login, but there's no 1st party Microsoft system that I'm aware of. I'm unaware of any way to enforce biometric/PIN AND password for login either, so anything extra than your user/pass for logging into your machine has some sort of 3rd party application apart of the login process.

 

I don't have experience with these systems, but I do have a friend who's company doesn't even give their employees their own passwords. They only use the authenticator app/biometrics to login, so if there's a problem, they have to contact the sys admin to resolve it.

 

I could see an aggressive 3rd party MFA software having way too much capabilities, like storing AD passwords in some way that can be read in plaintext. What MFA software do y'all use for login?

 

If it helps, you can see if the company even knows you're going to this site by checking the SSL certificate in your browser. If its negotiating to linustechtips and not some sort of local firewall certificate, then all they'll see is an IP and port that might not even be traceable back to a domain without some digging. If you see something else, then the company can read anything on that site in plaintext since they're effectively intercepting HTTPS traffic. Sonicwall's DPI-SSL being the version of this I'm familiar with.

[AbydosOne]

4 minutes ago, OhYou_ said:

your password is encrypted on your pc and sent to the server where it is decrypted back into cleartext. THEN it is hashed and compared to the stored hash.
it cannot be hashed on your pc because your pc is not the one verifying the password is the correct one

Hash algorithms are deterministic? If I hash my password or the AD server hashes my password, it's still the same hash... so why send encrypted-but-plaintext password when you could send encrypted-and-hashed password? Why have a remote cleartext step at all? All the server needs to do is compare the hashes, it doesn't need to know the original password string, right? Seems like a massive security hole to have cleartext passwords in RAM outside the client PC.

[OhYou_]

10 minutes ago, AbydosOne said:

so why send encrypted-but-plaintext password when you could send encrypted-and-hashed password?

does it matter?
 

[AbydosOne]

Just now, OhYou_ said:

does it matter?

Encryption keys can be stolen; hash functions need to be brute-forced (there are some optimizations, which is why salting exists, but there's no universal reverse function by definition).

[OhYou_]

Just now, AbydosOne said:

Encryption keys can be stolen; hash functions need to be brute-forced (there are some optimizations, which is why salting exists, but there's no universal reverse function by definition).

if the server expects you to send it a hash to authenticate, then a hacker can simply send it the hash and get in. why would they need to brute force it.
there is no difference to what you are describing

[RockSolid1106]

12 minutes ago, OhYou_ said:

if the server expects you to send it a hash to authenticate, then a hacker can simply send it the hash and get in. why would they need to brute force it.
there is no difference to what you are describing

I think you're confusing hashing with encryption.

[AbydosOne]

20 minutes ago, OhYou_ said:

if the server expects you to send it a hash to authenticate, then a hacker can simply send it the hash and get in. why would they need to brute force it.
there is no difference to what you are describing

This is different scenario than we're discussing.

 

If a bad actor had direct access to the server, we can surmise that encryption keys are either known or bypassed.

 

If I send encrypted plaintext of my password, bad actor now knows my plaintext password. If I send encrypted hash of my password, bad actor knows my hash, but not the text.

 

Either way, they can (in theory) use that password/hash to authenticate my account on this particular authentication system. The utility of knowing a password is to try it on different authentication systems. Assuming competent authentication design, the hashes will be salted to a particular application and submitting them to a different one will not result in a valid authentication (not saying there aren't incompetent ones out there).

 

My presumption is that AD servers store that password as a salted hash, and only ever receive a salted hash from the client via encrypted (TLS/SSL) channel (which seems logical, right?). So how does IT (functionally existing at the "direct access to server" point) know enough about the contents of my password for it to not pass audit if the plaintext is never sent to the AD server and (presumably) they didn't spend the time to brute-force unhash everyone's passwords?

[Agall]

5 minutes ago, AbydosOne said:

This is different scenario than we're discussing.

 

If a bad actor had direct access to the server, we can surmise that encryption keys are either known or bypassed.

 

If I send encrypted plaintext of my password, bad actor now knows my plaintext password. If I send encrypted hash of my password, bad actor knows my hash, but not the text.

 

Either way, they can (in theory) use that password/hash to authenticate my account on this particular authentication system. The utility of knowing a password is to try it on different authentication systems. Assuming competent authentication design, the hashes will be salted to a particular application and submitting them to a different one will not result in a valid authentication (not saying there aren't incompetent ones out there).

 

My presumption is that AD servers store that password as a salted hash, and only ever receive a salted hash from the client via encrypted (TLS/SSL) channel (which seems logical, right?). So how does IT (functionally existing at the "direct access to server" point) know enough about the contents of my password for it to not pass audit if the plaintext is never sent to the AD server and (presumably) they didn't spend the time to brute-force unhash everyone's passwords?

So with my understanding/research, they'd be either intercepting it while its in plaintext, so at the local level with software, or they've somehow modified AD to be read/write with passwords. 

 

More than likely, they're just doing what a ton of IT departments do which is bloviate their capabilities to scare employees into complying with arbitrary decrees they can't actually enforce.

[AbydosOne]

Well, I'll be... IT got back to me...

Quote

Thanks for your interest in security, and for reaching out! Your password is not stored or accessible in plaintext. We conduct our audit on the encrypted hashes of the passwords through brute force, and if a matching hash is found then we know that password was weak. This process largely involves testing the known hashes of previously breached passwords from data leaks and common password patterns. For context, a hash is a one-way encryption of plaintext that creates a unique output (so if we find matching hashes, we know we’ve found a weak password).

 

They actually just dictionary/brute-forced it. That's actually kinda neat.