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 john.smith@foo.com 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.
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.
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.
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.
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.
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.
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.
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?
> 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.
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.
> The third thing is to match against specific leaks. E.g.: if you have john.smith@foo.com 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.
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 spam@jeroenhd.nl is in the list is the only email address with 0xABCDE as the start of the hash, and the full hash being 0xABCDE0000; now bizniz@dijonman2.com happens to have the hash 0xABCDE1234. You transmit ABCDE to the backend, but even with the unique five letters of spam@jeroenhd.nl, how can the server possibly know if you're checking spam@jeroenhd.nl (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 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.
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.
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
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.
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
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.
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
indeed, only when using a microsoft account, which by the way is now required in the latest isos.
you can still bypass it but it requires being offline for the install. that being said, there are still many laptops with older windows version preinstalled that do not have the requirement; however users that don't care about this will just click the MS account option because the button was kind of hidden.
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.
It's actually still there and no need to be offline. Tested this the other with a brand new win11 22h2 install drive.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Hey, I keep seeing people claim biometrics somehow fix the password problem, but I feel like this is just a password you can't change? I can't change my fingerprints nor my retina, but if that data ever gets leaked, then that's vulnerable forever?
In my mind, there's no world where one could make a biometric scanner that couldn't be spoofed (presumably with an arduino USB interface) and then when all these corporations with the worst security (Facebook, Experian, etc) leak my data, can't anyone log into my account?
My country has my fingerprints because I have an id document like everybody else.
A number of states around the world have my fingerprints too because I entered those countries as tourist and I had to put at least one finger on a reader.
Maybe some country included mine also have my retina scan, I had to look into some cameras sometimes.
All those biometric information could be leaked, sold by corrupt civil servants or exchanged with other countries so random passwords generated by a password manager protects me more than biometric information. Am I wrong?
Of course some site could store and share with whoever they want my cleartext password before hashing it but I use one different password per site.
>All those biometric information could be leaked, sold by corrupt civil servants or exchanged with other countries so random passwords generated by a password manager protects me more than biometric information. Am I wrong?
I know of zero biometric implementations where your biometric data is uploaded to the server for verification. All the biometric implementations I've seen (windows hello, icloud passkey) perform biometric checking on device and send cryptograms to the server, which would be as secure as random passwords.
The point is that the raw unencrypted "secret" - your actual fingerprint or retina print - is directly collected for various purposes by various agencies, which can easily leak it.
However, even worse than that, your fingerprint in particular is something you leave literally everywhere you go. There was even a demonstration of someone copying Gerhard Schroeder's (German PM) fingerprint from a still photo of him from a bottle he had touched, and then creating a mold which fooled a sensor they had access to.
I'm sure that there are plenty of nasty scenarios.
This is one.
1. The attackers create my.name@somedomain.com / my.name.12345@gmail.com and/or use a throw away phone number (especially if the email provider uses some 2FA linked to a phone.)
2. They register an account on a web service using that email or install an app on that phone, maybe a virtualized one. Upload a picture of me as icon or fake one.
3. Use my fingerprints on their phone to get through any possible biometric 2FA.
4. They are me.
If they find a way to automate all those steps or make the labor costs small they can register a lot of bots that are real people, because 2FA says so. It's up to their imagination to find a way to profit from that.
We have id card, which contains client authentication certificates. The procedure on acquiring ID card is the same as passport and carries the same legal power. You have to show up in real life and they take your fingerprints, photo and issue you ID card. ID cards will actually be mandatory for everyone beginning 2023-01-01 - up until now they are optional but very much favored around my circle. There is a fair amount of stuff you can only do with ID card (remotely):
- Set up smart-id for 2FA for banking app in your smartphone. No, I don't have option not to use 2FA.
- Official communication with .gov entities.
- Signature & timestamp service
- Remote notary services (requires video presence and showing ID card additionally to actually using it to put digital signature)
- Logging in various sites (banking, government entities)
- Recovering from lost second factor at national TLD DNS registry.
This is the ultimate authentication mechanism that services use to allow you to perform so much.
To authenticate & put down signature, you must use dedicated PIN code for each of those operations. And of course you must possess the card (use card reader).
PS- Just spotted ftrotter's question for the first time. I also worked in healthcare IT and prototyped a PII protecting schema. Alas, my POC also flew like a lead zepplin. No password recovery. This strategy requires GUIDs, aka RealID in the USA.
"I am building an application with health information inside. This application will be consumer-facing with is new for me. I would like a method to put privacy concerns completely at ease. As I review methods for securing sensitive data in publicly accessible databases I have frequently come across the notion of database translucency. ..."
I could have written that. Oh well. Someone in much the same situation, having the same questions, and then reaching about the same answer is somewhat validating.
10+ years later, I'm sure there's now dozens of us advocating Translucent Databases techniques.
I long wondered about this... How does card reading work?
Are regular smartcard readers compatible? Does the card have NFC for phones? Can you use them under Linux/mac? Do regular browsers work with it? (FIDO/webauthn).
Or is the card reader a standalone device, like my bank uses, where you key in your PIN, and it gives you a one-time code, or a response to a challenge?
Generally, you're not logging in directly with the biometric data. The biometric data never leaves your device, it is just used to protect some kind of secret key on the local device that it actually uses for the authentication when logging in. If you need to log in another device, you would use an existing device to confirm the new login or you would need to use some other authentication method.
Well, I got fingerprinted by FINRA when I took a job at a trading company, and I have been fingerprinted by the US government multiple times. When I went through China once, they needed a fingerprint or two. Same for my Brazilian visa.
Biometric information leaks through other means, and if you rely on it for security, you are letting a lot of people in.
Yeah biometrics are not password replacement. The solution everyone uses today is "something you have (2fac device) + something you know (password)" -- the 2fac device needs to be a OTP generator, but you could even further secure this by requiring biometrics to generate the OTP (e.g. imagine a security key that refuses to acknowledge touch unless it senses your fingerprint).
Biometrics without the other two doesn't help anyone.
> but I feel like this is just a password you can't change
Not quite. IBM has (had?) a research program on "cancelable" biometrics. I do not recall perfectly, but I think they were tweaking the encoded biometric sensor data before committing it to DBs. If there is a leak, one can redo it with a new tweak (like a new salt or nonce).
The worst thing about biometrics or hardware devices is that someone can force you to give them out in my opinion. If I have a 6 word passphrase which I remembered, no one can get it unless I give it to them (Yeah, I know there's still some methods https://xkcd.com/538/).
In the Netherlands, the police can hold your finger to the fingerprint reader on a device they confiscated (might need a court order, or might depend on circumstances if there is an imminent threat to life or something), but they cannot order you to work on your own prosecution in general. Why, then, you can be ordered to put your finger on the pad, I have no idea, but it has been ruled that you cannot be ordered to tell them a password.
Then again, the secret services have been allowed to order giving up passwords since forever.
The solution there is to set aside a few less-used fingers which, when applied to the scanner in sequence, tell it to perform a secure wipe. I'm left-handed so I use a few fingers on my right hand plus my left little finger for access, this leaves enough fingers for a fingerprint-directed wipe command:
left index followed by
left ring followed by
left middle => Wipe
There is bound to be an app or option in some AOSP-derived distribution for that, if not you got the idea here.
You will almost always use one or two fingers to unlock your phone due to the fingerprint readers position and the police might be intelligent enough to ask you to put that exact finger on.
> Of course, someone might be able to clone your head shape.
This is from 2005:
> Police in Malaysia are hunting for members of a violent gang who chopped off a car owner's finger to get round the vehicle's hi-tech security system.
I guess this is a question of threat model. I hope nobody would want to chop of my head just to unlock my iphone. But this always reminds me of the scene in "Demolition Man" where Wesley Snipes spoons out someone's eyeball to open the biometrically locked door of his prison.
What I'm hearing you say is that the hardware has baked-in private keys. That is not biometrics, that's public-private key authentication. People already do this with ssh/pgp private keys on a hardware token. Which is a good idea, but it has nothing to do with biometrics and is not something you need to sell your soul to apple for.
> It’s also more secure than a password on a phone because if you’re using it in public someone can watch you type your password in.
I'd rather hold a hand over a PIN pad than having to wear a mask to prevent my face from being scanned in public.
> What I'm hearing you say is that the hardware has baked-in private keys. That is not biometrics, that's public-private key authentication.
Even if you could write your sensor's face data into someone else's phone, you still wouldn't be able to authenticate with it, because it doesn't have the same sensor. It's not just different keys, the fixed layout of the IR pattern is different.
> I'd rather hold a hand over a PIN pad than having to wear a mask to prevent my face from being scanned in public.
And not sure what the actual threat model here is, but I don't think strangers can scan your face in a way that's useful to Face ID. (Wearing a mask doesn't stop general identification technology, it doesn't even break Face ID anymore.)
I don't think they meant respiratory masks to hide from your head being scanned, especially if the algorithm doesn't look at that part of your head.
> Even if you could write your sensor's face data into someone else's phone,
Since the keys presumably aren't retrievable from the hardware, it doesn't matter if there are random or intentional production flaws in the sensor itself: you need the original hardware anyway. You just need to trick it into doing the authentication. That's the part where biometrics are involved, the part where you present it with a username so to say. The rest is private key authentication.
The rockyou.com insight was new to me. I hadn't heard of this breach somehow. I was wondering how they had 32m users and read some more on Wikipedia and they had Facebook apps and some MySpace plugins.
From Wikipedia
> In December 2009, RockYou experienced a data breach resulting in the exposure of over 32 million user accounts. This resulted from storing user data in an unencrypted database (including user passwords in plain text instead of using a cryptographic hash) and not patching a ten-year-old SQL vulnerability. RockYou failed to provide a notification of the breach to users and miscommunicated the extent of the breach
Fun fact: rockyou.txt by now is probably one of the most common/famous wordlists out there, used for doing various types of dictionary attacks and the entire list ships by default with lots of tools, including Kali Linux which is a common distribution for pentesting.
> one of the most common/famous wordlists out there, used for doing various types of dictionary attacks and the entire list ships by default with lots of tools
Famous, ships by default, agree, but actually used? It's really low quality, I've mostly seen it used for CTFs: because it is so common, the organizers / challenge makers think picking a password from this list is fair game for a challenge where the trick is to crack some user password hash without requiring proper cracking hardware. In the real world, it can be a starting point but it's not really used much anymore.
Things like the linkedin list and newer lists are more accurate, especially when combined with rule sets that add additional transformations (add an(other) exclamation mark to a password, change o to zero, combinations of these things, etc.)
> Instead of passwords, we should use something like FIDO, which allows users to log in using a security key or biometric information.
The problem "in the real world" is that people will lose these keys all the time. I mean, I agree, passwords need to die, and hopefully some of the work that is being done by Apple and others will help bring on an end to passwords, but you can't really talk about replacing passwords with FIDO keys without talking about how to deal with account lockouts, which is a real, hard problem.
Similarly, biometrics may be good for a user ID but they make horrible passwords. These days fingerprints and irises can be copied from photographs.
This is typically the problem with silver bullet solutions. You can easily look at the solution that’s been in place for decades and see where it fails, because you have decades of data to look at. You look at your new shiny solution, and you can see that it solves all of those problems. What you can’t see, because you don’t have decades of data to look at, are all the new problems that will come up with the new solution. You’ll notice some of them, and you can try to patch over them, but you’re bound to miss a lot.
Which isn’t to say that you shouldn’t go with the new solution anyway. But I’m always skeptical when all people say is “it solves all the existing problems.”
Are these used in conjuction, or any one will do? If it's the former, it seems like it would make the problem of loss worse. If it's the latter, then it seems you've offered a variety of ways that someone can access your systems - steal a key, copy biometrics, guess the phone password etc. - the weakest one will do.
Only needing one means you have the "lowest common denominator" of 2FA. E.g. authenticator apps are vulnerable to phishing, while FIDO keys are not. Adding FIDO key as an optional second factor doesn't really add much security if people can still be phished using a MITM attack using the authenticator TOTP.
Exactly. I asked Per Thorsheim once about resetting 2FA creds, something that is viable for banks etc. that hold a lot of semi-private data which can be used to verify your data but for a much smaller startup with basic account info.
He said he didn't know how it would be done securely.
I see a lot of attacks are due to account takeover and we currently seem torn between allowing an attacker to circumvent the 2FA by account reset or leaving someone unable to access their account for ever.
I started scanning 2FA codes into two phones, my main one and one that I leave hidden at home (and switched off) for backups. Knowing my luck though, I'll ned to access the one that I forgot to scan into the second phone!
You could also print the 2FA setup codes (like on actual paper :P) and store them in a safe or otherwise secure location. Along with the backup codes probably (or maybe each goes to a different location, or copy of each in 2 locations, one remote, depending on how important access is and how hard it would be to get it back without that information.)
I hope that the availability of using device-based (using the built-in hardware in a device they're less likely to lose like a phone/laptop) or account based (like the passkeys synced to iCloud/Google/Microsoft) will help mitigate the issue of people losing them. Regardless of which option they use though, they should treat them like home/car keys and have backups in place.
As for the biometrics, when people talk about biometrics for authentication, they are usually talking about using the biometrics to unlock something stored securely on a device. Without the device that has the actual credential being used, the biometric that has been copied doesn't do attackers much good.
Don't worry, all I can see is ••••••••••••. The browser builds in technology so that it conveniently shows you your password (BingoBingo77), but all I can see is ••••••••••••. Neat, right?
> Don't worry, all I can see is ••••••••••••. The browser builds in technology so that it conveniently shows you your password (BingoBingo77), but all I can see is ••••••••••••. Neat, right?
Hey, waitaminute! How did you know that my password is "BingoBingo77"[1].
Yubikey is here since 2007... and Windows 10 still doesn't support passwordless, security key only! login. They want you to register a goddamn MS account too...
Microsoft Outlook and live.com logins can use security keys, in fact they are accepted as a single authentication factor rather than a second one: supply your Yubikey and you're logged in without username or password!
However, Windows Hello in Windows 10 does not support local logins with security keys. This may have changed last week with a recent update, but it definitely wasn't supported when I installed Windows last Christmas.
I think it's Microsoft's opinion that security keys are too secure for consumer use; if a consumer is locked out of their personal device due to mismanagement, theft or loss of a hardware key, that's a support headache and liability burden that they're unwilling to take on at this point.
>In fact, pretty much the only case where complexity and length matter is when we’re defending against offline password cracking. But for every other case in the threat model where passwords are stolen, length and complexity simply don’t matter.
The idea is that most passwords are stolen when they are plaintext. So it only matters that the password is unique to that system. Offline password cracking is relevant for cases like the passphrase used to protect your PGP or SSH keys. Then length and complexity is important. Stuff like the suggested FIDO is the same sort of thing. If you need to protect the FIDO key information then length and complexity of your passphrase is important where offline password cracking is relevant.
> Another legitimate case for password cracking is if someone in accounting encrypted a spreadsheet and then got hit by a bus and other employees needed access to that document
I feel now is the time to shill my free cloud, 18-character length password generator [1]. It is a completely serious password generator only requiring a Twitter mention (@) to summon.
Nice. Seems to be a real improvement over diceware.
> We manually checked and attempted to remove as many profane, insulting, sensitive, or emotionally-charged words as possible, and also filtered based on several public lists of vulgar English words
I kind of wish they had a list _without_ this step though. Vulgar and emotionally charged words are easy to work into stories and easy to remember.
As someone also in this business, I would speculate that they give such advice because it is currently effective. It's hard to say whether that will remain the case when biometrics are more widely used. Perhaps, then, we find that storing hashes of all sorts of biometrics server-side is not such a good idea after all. Or if done client-side, then you basically have public key authentication which also exists today and is often recommended for things like ssh -- don't need biometrics for that, how you unlock your ssh key is up to you.
I've really embraced biometrics now that I understand that they're effective for certain use-cases when properly implemented.
For example, the primary threat model for my mobile device is a combination of shoulder-surfing and theft, because I ride a lot of public transit. So it's way more secure for me to touch the fingerprint sensor rather than constantly peck in my password while I'm being observed. A common criminal or homeless dude who steals/finds my phone won't know my password because I'm not revealing it, and they're unlikely to have access to my finger or its print.
If my threat model were different, say law enforcement/TSA confiscation or something, I might be more worried about walking around with fingerprint auth enabled. So if I head to the airport or enter some other high-risk area, I might consider disabling that, removing the sdcard and/or SIM card temporarily.
Biometrics as a way for my personal device to recognize my physical presence is mature tech, and useful for consumers in ways that passwords aren't.
Most modern biometric auth is implemented by the biometric device acting as an HSM and only agreeing to perform the cryptographic operation with its secrets if the proper biometrics are provided. Biometrics are never directly sent to the service you're authenticating to, instead it's using a form of PKI in the background where your biometric device is an HSM storing the client certificate.
This is less secure against dedicated attackers with physical access, but much more secure against remote attackers as there's usually no way to provide the biometrics to the HSM in software and the authentication key from the biometric device can't be stolen so you must keep persistent access to it to be able to use it every time you need to authenticate.
Things like FIDO Yubikey are basically a password unlocked by biometric information so someone needs the key AND your biometric information to unlock it. Even if someone knew your "biometric" information, they would still need the key.
meh. pro hackers do not crack or bruteforce passwords except as a last resort. they instead find some critical vulnerability that bypasses the need for passwords, or steal the browser sesion, or use malware. this is how so many people got crypto stolen despite strong passwords.
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 john.smith@foo.com 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.