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...
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.
Nevertheless, did GP mean Kerberos tickets by "domain credentials"? How does Kerberos prevent the use of password managers? I'm confused.
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.
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.
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 [email protected] is in the list is the only email address with 0xABCDE as the start of the hash, and the full hash being 0xABCDE0000; now [email protected] happens to have the hash 0xABCDE1234. You transmit ABCDE to the backend, but even with the unique five letters of [email protected], how can the server possibly know if you're checking [email protected] (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.
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.
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.
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.
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).
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.
their reason for this is that you need to save the bitlocker recovery key somewhere, and they don't trust the users to do it properly (not even mentionning the UI for this would be horrendous) so it saves it to OneDrive.
The workaround is to click "connect to my work account", then "domain join". Not Azure AD, but regular AD. This then presents you with the classic offline account creation dialog. It doesn't even ask you what the domain is.
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.
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.
> 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.
Not to mention insiders that are bad actors.
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.
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.
"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.
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 [email protected] 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.