[jiggawatts]

Some rules of thumb:

All Windows passwords shorter than about 10 characters shouldn't be considered secure, as the NT Hash at this point is so easily reversible that it's basically a "light obfuscation" at best. A single GPU can crack all 8-character passwords in minutes. The single best security setting on a Windows network is to increase the minimum password length to something like 14 characters. Use 20+ for privileged or service accounts.

The second best thing to do is to scan password hashes against "top password" lists and reject any that are in the top-N, where its up to your business policy what 'N' is. I recommend at least the top 10,000 most common passwords being outright rejected.

The third thing is to match against specific leaks. E.g.: if you have [e-mail] and there is a leak of his email and password where the password matches your records, force a password change immediately.

All of the above assumes that MFA is in place, your servers are patched, and there are extensive audit logs on all authentication attempts.

[mr_mitm]

Note that cracking the NT hash rarely results in escalation of privileges due to the pass-the-hash vulnerability. There is almost never any need to crack NT hashes.

The attacks you need to defend against are: 1) online password guessing, 2) Kerberoast, 3) cracking NTLMv2 authentication handshakes, 4) cracking DCCs (Domain Cached Credentials).

1) is solved by applying a moderate list of banned passwords, a sensible lockout threshold and MFA for things on the internet.

2) and 4) are only against high privileged accounts, as they imply access to a low priv account already. (You need an account to request kerberos tickets and if you can read DCCs, you usually can compromise at least a computer account). High privilege accounts should never be accounts that you log on with before you can access a password manager, so they should simply use a 16 character randomly generated password. Make this a requirement in your org, perhaps crack passwords yourself regularly to confirm.

So you're left with 3) which is effectively salted and orders of magnitudes harder to crack compared to NT hashes.

I talked about this at Troopers; unfortunately the video is not yet available. http://troopers.de/downloads/troopers22/TR22_BetterPasswords...

[GoblinSlayer]

And guess what, in windows networks authentication is done with domain credentials, but those are bound to your physical console, so a password manager can't be used for remote authentication in this case.

[mr_mitm]

What do you mean by "domain credentials are bound to your physical console"?

[yabones]

Windows (in a domain environment) sends a Kerberos token for network auth which is generated on sign on and signed by a domain controller (authentication server). When the user authenticates to a network service, the token is sent to the service to validate without the need for an additional network hop to the domain controller.

Each "console" is a "seat" sort of like a PTY emulating a serial connector. Whether you're hands on keyboard or using a remote desktop connection, your login session has one kerberos ticket which is used for authentication automatically.

https://en.wikipedia.org/wiki/Kerberos_(protocol)

[mr_mitm]

Yes, I know how Kerberos works. The TGT is not bound to anything though, it can be stolen and reused elsewhere. And in the default setting, an attacker doesn't need to rely on Kerberos as an authentication mechanism, since NTLMv2 support is widely available. It's available by default.

Nevertheless, did GP mean Kerberos tickets by "domain credentials"? How does Kerberos prevent the use of password managers? I'm confused.

[GoblinSlayer]

When you log into the system, a keyboard is usually the only device you have to enter the password, unless you store in on paper or on a second device. And even if you store it on paper and the password is long, some operations like lock screen (that can be also misconfigured by domain admin) become expensive and thus impractical.

[mr_mitm]

Sure. That's why I recommended password managers only for high privilege accounts. Passwords of those accounts should almost never be typed on a keyboard. They can be looked up by authorized personnel who logged on first with their low privilege account.

[paulryanrogers]

Is this still true now that LM hash v1 support has been dropped?

[gruez]

NTLM v2 isn't much better https://twitter.com/TerahashCorp/status/1155128018156892160/...

[tinus_hn]

It is much better but v1 is simply so terrible ‘much better’ is very far from good enough.

[yrro]

Can a Windows expert chime in here. Why is the NT hash even calculated any more? Is it still the default? Can group policy be configured to tell everything to not used to disable NTLM everywhere? And can't AD be configured to disable RC4 everywhere? Do MS ever plan to properly deprecate NTLM/RC4, disable it in new domains and start displaying prominent warnings when they're enabled?

[mr_mitm]

> Why is the NT hash even calculated any more?

For legacy reasons, I assume.

> Is it still the default?

Yes

> Can group policy be configured to tell everything to not used to disable NTLM everywhere?

It can, at least for domain-joined Windows machines. Most environments can't afford to disable NTLM though, because some legacy systems rely on it. However, Microsoft recommends disabling it.

> And can't AD be configured to disable RC4 everywhere?

Yes

> Do MS ever plan to properly deprecate NTLM/RC4, disable it in new domains and start displaying prominent warnings when they're enabled?

I'm not aware of such plans. If I were to guess, then I'd reckon they want everyone to move to Azure and let onpremises AD die.

[GoblinSlayer]

It's a GPGPU offline attack against a hash that can be recovered from a turned off system. So is only realistically useful to learn your password habits. I once cracked my forgotten password this way.

[dijonman2]

> The third thing is to match against specific leaks. E.g.: if you have [e-mail] and there is a leak of his email and password where the password matches your records, force a password change immediately.

I’ve wanted to do something similar but how would you do this without direct access to HIBP’s data?

I don’t want to send customer email addresses to a third party, at least not without a contract.

[jeroenhd]

For what it's worth RE: HIBP, the lookup is never actually done on an email address. If you use the API (https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR..., or https://api.pwnedpasswords.com/range/3E398 to see the API result), you transmit 5 characters of the SHA1 hash of the email address and check if the full hash is in the list.

This makes it possible to use the API without worrying about user privacy as long as you keep checking the email addresses, even after indicators of compromise. Suppose [e-mail] is in the list is the only email address with 0xABCDE as the start of the hash, and the full hash being 0xABCDE0000; now [e-mail] happens to have the hash 0xABCDE1234. You transmit ABCDE to the backend, but even with the unique five letters of [e-mail], how can the server possibly know if you're checking [e-mail] (a listed entry) or your own address? The server provides the list of hashes (only 0xABCDE1234) and you verify on your end that 0xABCDE1234≠0xABCDE0000, proving that your email is unlisted.

On average, the returned amount of hashes is claimed to be 381-584. That means that even if your customer is on the list, they're at best one of the ±478 hashes (on average) in the response if they're even listed at all!

The full explanations is here: https://www.troyhunt.com/understanding-have-i-been-pwneds-us..., it's worth a read if you're interested. In practice, I wouldn't worry about your customers' data in this case, because you're not really sending anything identifiable to a third party.

There are less privacy conscious APIs to HIBP, but the range search is probably the easiest and most private way to get the checks done.

All of that said, I use random passwords for every service I use and I'd very much like to opt out of your auto reset system. I'm in favour of adding the feature (more websites should, in my opinion!) but I don't like to be forced to change my already unique password if I don't have to.

[TheMaskedCoder]

> you transmit 5 characters of the SHA1 hash of the email address

You don't use email addresses at all with Pwned Passwords. The documentation says "first 5 characters of a SHA-1 password hash", not email-address hash.

HIBP does not have a way to search for which password hashes are associated with a given email address, as this would be far more useful to attackers than to victims. The only data that Pwned Passwords exposes is a list of password hashes and the number of times that hash was used. The expectation is that even if that leaked password was actually for someone else's account, you still shouldn't be using it.

[jeroenhd]

Whoops, you're right, got the API confused. You can't just search for email addresses.

Still, though, you can implementtthis check every time someone logs in (and the password is transfered over the wire) which should catch most bad passwords/password reuse cases.

[dijonman2]

I had no idea, thank you for opening my mind to this!

[jve]

You HAVE direct access to HIBP data. Albeit hashes only which are enough to tell if password has been compromised before or not. You can download pwned passwords list and do checks locally: https://haveibeenpwned.com/Passwords

[Scion9066]

If you don't want to send stuff to others, then you would generally need to either get the email address data another way (e.g. collecting the data from breaches yourself on behalf of your org) or download the Pwned Passwords data and setup a system to check against compromised passwords locally.

[2Gkashmiri]

i am forced to use windows machines in my own office. i know people and kids who use windows machines. with new installs, they are being taught to set a password, which is fine for a bank or a super secure machine that holds financial data but for kids and grannies and drone office workers, this gets tiring. Now you are saying to FORCE them to use 14+ characters. HOW? why? in linux there is a "auto login with this password" which i love to use because there is nothing so private in my machine so i can just go in and out

[vladvasiliu]

Because with more and more people having laptops, they probably don't want their pictures or what have you in the hands of some random thief who happened to steal it.

Newer computers also usually come with a TPM, which allows you to not have to type the password every time. If the PC doesn't have a fingerprint reader [0], it can use a shorter PIN.

---

[0] I know a fingerprint isn't a password, but for protecting low-profile individuals who aren't a target for actual data theft (as opposed to opportunistic old-fashioned property theft) it's likely good enough.

[2Gkashmiri]

the thief can just use a live cd and copy stuff, i mean that is what i do when i bork the windows install. i don't use bitlocker and i suspect many many people don't so this is merely an inconvenience

[MayeulC]

I think windows encrypts more and more by default.

TPMs are not unlocked if they can't validate the boot chain (live cd), so you'd need the disk password (and full user password).

[Nextgrid]

Did a Windows 10 Pro install just a couple days ago and BitLocker still wasn't on by default.

[vladvasiliu]

I think it's only turned on when you connect it to an online account.

It's still possible to only use a local one, but it's in an unexpected place, so I expect most people to go the online route.

[2Gkashmiri]

dont you disable secure boot and go to legacy mode ? i do when i install linux or windows both as a habit

[MayeulC]

I haven't performed a single windows install since 2013ish (was it 8.0 beta?), but I'm saying this based on how often I see it enabled. Companies do it, and probably manufacturers too. I'm less sure about the install media, true.

Regarding secureboot, I went through the pain of configuring it under Linux (creating and importing my own keys), before realizing it was of little use without a TPM. Turns out both Windows and Linux can't "own" the TPM at the same time, IIRC (work laptop has a windows partition). I ended up learning my randomly generated >15 char disk decryption password by heart.

[vladvasiliu]

On my work laptop, on which I dual boot Arch and Windows, I've just signed MS's keys with my own key and disabled booting from anything else than the internal drive.

I'm not sure what you mean by "legacy mode", but I'd expect that to mean "BIOS compatibility mode", and that's not really related (apart from presumably disabling secure boot). I actually prefer UEFI, this allows me to avoid wasting time with a classic bootloader.

[justsomehnguy]

https://duckduckgo.com/?q=auto+login+with+this+password gives you multiple ways on how to do it on Windows

> nothing so private in my machine

In YOUR machine. Chances of someone abusing the data on a stolen/lost laptop is small, but not non-existant.

[macintux]

Something I’ve wished companies would do: publish (on an internal site) all of their employees’ previous passwords each time they’re rotated. Users would be compelled to create better passwords out of sheer embarrassment/competitive spirit.

[ollifi]

I sort of wish companies would not have employees passwords. Hashing should be standard practice.

[ovi256]

It must be, but publishing old passwords can still be done by saving the old cleartext password on password change.

[BeFlatXIII]

As in store "old password" as cleartext on its final use?

[macintux]

Yes, that was my initial thought on how to make this possible. In my case, the company where I contract has a dedicated application (on Mac, at least) for password changes: record the old password and share it once the new password has taken effect.

[dotancohen]

The last password, to be posted, could be stored in plain text on the password change form submit action. Before that it is only ever committed to permanent storage as a hash.

[vivegi]

Wouldn't that just be another attack surface? Chances are some of those rotated passwords may be used in other sites and this just exposes the company and the user to additional risk.

Not to mention insiders that are bad actors.

[macintux]

It gives added incentive to the company to make sure all of their internal passwords are managed via SSO so the users don’t continue to use a password on non-integrated systems after it’s rotated centrally.

And as long as employees are warned in advance, they should be aware of the risk of re-using passwords, which already exists today. If anything, this highlights the fact that if employees are using their company password for some other service, they’re placing their employer at risk.

[Arainach]

Not all sites are customer sites.

I generally use unique passwords for everything, but I worked many years at a company with a 3-month password rotation policy, and coming up with high-entropy yet memorable passwords was sufficient work that many accounts on machines on my home network used some retired passwords from there.

[kyriakos]

Policies like this one is what makes people write their passwords on post it notes. It's hard to create new memorable passwords every month or two so people will either keep using a pattern or be forced to write it down on paper. MFA is the way to go.

[macintux]

If the company is forcing password rotations every couple of months they’re too broken to successfully handle this anyway.

[kyriakos]

Anecdotal but I worked for a non tech company over a decade ago that had a monthly password change policy. When I started at the company my desk wasn't ready the first day so I was seated on the workstation of another employee who was in vacation. First thing I saw was his password on a post it under the keyboard.

[Tangurena2]

I worked at a place that had such policies; it is a national engineering lab. They are owned (mostly, some are joint ventures with universities) by the Department of Energy (who builds and owns America's nukes - they're just leased to the Dept of Defense). While my lab had nothing to do with nukes, some of the other labs made them. So we got many of the same security policies that Los Alamos had. Which meant it took me about 45 minutes to figure out a new password that wasn't too close to one I previously used, nor did it have a 3+ letter word in any language (I have no clue which languages they tracked) forwards or backwards.

[EnderWT]

You want companies to store passwords in plain text?

[kleiba]

Only the no-longer-in-use passwords, which could be collected at the point in time when the user changes it to a new one.

[arjvik]

Plus, it would mean people would stop just incrementing a number at the end if it revealed their pattern.

[exhilaration]

If companies want us to stop incrementing a number (guilty!) or writing our passwords on post-its stuck on our monitors, they should stop requiring us to change our passwords every freaking month. I think it was only in 2021 that NIST suggested the password change frequency should be yearly.

[amlozano]

I think NIST has actually recommended against forced rotation of passwords (unless they are breached) since at least 2017.

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

- NIST SP-800-63B Digital Identity Guidelines - Authentication and Lifecycle Management

--

A large part of me wishes they made this a SHALL NOT. It would have caused chaos with other standards, but it would have been the right thing to do.

[thesuitonym]

You underestimate how much people care about a revealed password. I've definitely heard water cooler talk about how some have "beat the system" by using a certain password (That they just tell the person they're talking to!) and the year.

[sh34r]

Personally, I wish fewer companies would store passwords in plaintext!