I did a consulting engagement a few years ago where we cracked 60% of passwords in a 40k user directory in under 3 hours, on a laptop. Every password met NIST complexity requirements of the time.
Would love to know how long it would take to crack
5ae2b1ce4999dfd2c8f1a57509650e75
as a password.
Hell even 5ae2b1ce4999dfd2 is probably more secure than the majority of passwords chosen by users
iOS has the right approach: they suggest random passwords in Safari and explain why, then save them in a local hardware-encrypted store with biometric quick unlock. Downside of course is they also sync to Mac and don’t have the same usability in other contexts. Windows support was recently added, but is only as secure as the TPM option and firmware of your BIOS/CPU chips and given encryption requires Pro, it’s possible some security features also require Windows 10 Pro. I’m also not sure how iCloud for Windows communicates with Chrome or if that’s been documented somewhere. https://support.apple.com/en-ca/guide/icloud/mmfeee20145e/ic...
A permanent solution is to skip the password and just use biometrics and machine identity, such as with FIDO2. Obviously not required in every scenario, but much more secure than a re-used password, even one that hasn’t yet leaked, because it might still (be leaked due to re-use, that is). Add to that tracking of which machines and locations a user logs in to for flagging suspicious “I can’t access my account,” requests etc. Encourage users to log in from more than one device if they can to help regain access automatically if a device is lost or reformatted…
So that's effectively the same thing as if the site only used FIDO2 - because that's the same technology Apple uses within Safari and other web browsers to implement Sign in with Apple.
You can do the same with your Microsoft account: https://www.microsoft.com/en-us/microsoft-365/blog/2018/11/2...
The big name left out of all this is Google. They seem to have embraced using passwords everywhere, except, oddly enough, on their passwords management website - https://security.googleblog.com/2019/08/making-authenticatio...
Every once in awhile Google Chrome will prompt me to sign in with a password, skipping the 2FA check, just to validate my identity. It's kind of pointless, really. If they can't trust my device to be secure, why are they asking me to enter a password on my device? That just weakens my account's security if they legitimately couldn't trust my device... Better to have my device validate its ID and my ID via Windows Hello or the same FIDO2-style biometrics and call it a day.
You can opt to replace any biometrics with a device-specific password that is more secure than other passwords because it never leaves the device or even an additional two-factor key, at the option of the device maker.
For example, you can use a separate FIDO2 key within Windows Hello for enterprise use cases against Azure AD instead of using biometrics to sign in to your computer.
Folks can choose what level of security they are comfortable with. For me, personally, and everyone I know, passwords are much easier to steal and reuse because they leak regularly, can be tested multiple times without consequence, and so on.
To be clear, I’m saying password managers are awesome but device-based security is more awesome. Add a local password to your device based security is more awesome still, but then so is having a friend approve your request or other additional layers of security. Biometrics are the new PIN code “minimum” not the best we can do but better than sharing one string of text with the rest of the internet and assuming it will never leak.
Note that the risk model is roughly identical if a device is lost. Just as with a compromised password, you would have to visit websites using the device directly and revoke its access. This is made simpler if you combine FIDO2 with OAuth2 because then you only need to de-enrol the device from Microsoft or Apple. OAuth2 provides an additional layer of protection because it can tell you when your device is used, and can add additional security factors such as notifying you when a login occurs that not every site might build. OAuth2 does this by replacing passwords with timed tokens depending on how it’s configured, so at minimum new tokens are logged.
The same applies to the use of short-lived credentials in AWS or other cloud providers vs using permanent secret tokens. When using permanent secret tokens, like passwords, these are often very hard to rotate without consequences because you do so very rarely. They are also subject to reuse on different machines. By comparison, a short-lived token can use machine identity on a cloud server to add an additional layer of protection, and depending on the authorization system could validate a local device, use of a second FIDO2 or biometric device, validate the server requesting delegate permissions on your behalf, and validate the duration and scope of data being accessed, all at the same time.
In highly sensitive scenarios, one could even use asymmetric encryption stored on devices to ensure that any intermediate or delegate servers cannot decrypt API responses, only the recipient of the data. Of course, you need a model to trust your client app, but App Stores notarization and containerization go a long way to making it easier to wipe and redeploy secure machines frequently, such as with every system update, optionally leaving user data alone.
If your fingerprint is compromised, where can get new fingerprints?
Device based security (like a FIDO2 key, or even a phone with an authenticator app) is great, beuacse when it's compromised, you can change it.
Biometrics though is even worse than a userID, it's public, left everywhere, and can't be changed
If your fingerprints are lifted/leaked from a glass, for example, then published, your attackers also still need physical access to the device you use biometric security against.
If that's public, such as your house front door, I agree, you've a problem. If that's your cellphone, then you have to ensure you don't leave your phone unsupervised.
The same is frankly true of other exploits that can be done in-person, such as USB attacks or PIN code screen bypass, and so on. Once you have physical access to a device, you can authenticate via many means, not just biometrics.
I'd point out that a password can also be compromised. https://xkcd.com/538/
But given a list of common words, it’s pretty easy to figure out how “Autumn2012!!!” will change with the seasons.
[1] https://google.com/search?q=0x5ae2b1ce4999dfd2c8f1a57509650e...
[2] https://google.com/search?q=0x5ae2b1ce4999dfd2+%2F+%28170+qu...
It's been a while since I fired up John the Ripper but it has low hanging fruit modes built in.
So even if you are using quite long simple alphanum strings of gibberish then seriously consider adding one or more character class into the mix eg capitals and easy to identify special chars like $£% etc.
To really go for gold why not mix entire scripts eg the usual en_* alphabet and say Bulgarian Cyrillic. Gasp as your keyboard mapper explodes! Alternatively, look into MFA.
I agree about incorporating other characters. As long as it's not "Dictionaryword1!" :) https://youtu.be/aHaBH4LqGsI
5ae2b1ce4999dfd2 is about 10^19 options.
Most passwords will come from a set of around 100 characters (52 letters, 10 numbers, about 35 symbols on my keyboard). An 8 character password would be 10^17 options.