Neither password is secure once it leaks, though. That’s the problem when people pick a secure password but then use it everywhere. This is why password managers are mandatory for secure passwords.
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…
Sign in with Apple, required by Apple for all apps with social logins, will only prompt you for a password when you don't have Face ID, Touch ID or a PIN set on your device, according to https://support.apple.com/en-ca/HT211687
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.
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.
Biometrics are simply the equivalent of tapping a FIDO2 button. They don’t increase security as much as they are a signal to authorize that prevents less dedicated users from opening the device. The device, not the biometrics, provides the security guarantee to replace a password.
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.
There's a difference. If your FIDO2 key has biometrics (such as touch ID) then it's still a FIDO2 key. It means if it gets compromised (lost or stolen, for example) then you need both the device and the biometrics to gain access.
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.
Bitcoin miners are doing around 170 quintillion hashes per second, so if all of those resources were put toward cracking these passwords, in theory it should take around 20 billion years for the longer one [1], or about 38 milliseconds for the shorter one [2].
Well OK but not all passwords are hex numbers! Given that testing a few simple classes the length of the shorter one takes about a second or two then that seems worthwhile.
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.
Yeah -- I assumed that a random hex password was chosen, and that the attacker does a brute force hex search (e.g. JtR with Incremental:LowerNum). Granted, in practice the attacker usually doesn't know the exact format, so they might waste additional time searching other formats.
I agree about incorporating other characters. As long as it's not "Dictionaryword1!" :) https://youtu.be/aHaBH4LqGsI
Maybe Bitcoin needs a “proof of proof of work” now. If some entity wanted to brute force an attack on the worlds passwords, the increased electricity and heat would be detectable. But they could hide the activity it inside Bitcoin mining. A proof would be needed.
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.
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