All Your Passwords Are Belong to FPGA
hackaday.com
hackaday.com
That's really not a lot considered the investment. A similar effort to crack SHA hashes would do trillions per second on CPU/GPU, or quadrillions per second on dedicated FPGA.
It is a testament to bcrypt success that it is able to slow down an attack by 5 to 10 orders of magnitude.
The lesson is unfortunately, that short passwords like 6 character long or common passwords in a top 1 million list can never be safe from cracking, no matter the algorithm.
Shouldn't this wildly depend on the bcrypt hash's work factor?
This is apparently because "benchmarks" tend to choose 5. But since sites don't actually use that work factor you should modify your assumptions appropriately.
When judging password (or other secret token) effectiveness, it's not just today's crack rate that matters, but 20-80 years in the future. Rates and costs are advancing / declining exponentially.
In summary, while browser and mobile OS vendors could cooperate to improve the situation with client certificates, as of now, there appears to be no interest from any party to do so, and unless it happens, it is not worth it to use client certificates at all.
The obvious solution, rather than syncing the certificates, would be to allow more than one client certificate per account. Each device would have its own certificate. If one device is compromised you need only revoke that particular certificate; other devices could still access the account.
To avoid the need to manually register multiple certificates for each account you could cross-sign the per-device certificates; i.e. if key A is registered, and key B is signed by key A, then key B can also be used to sign in, perhaps with a warning sent to the owner of the account about a login from a new device.
One option is each site you authenticate to needs to issue you a certificate for your identity on that site. Web browsers would presumably become responsible for minting the CSR during registration, and then hanging on to however many private keys and certificates (dozens? hundreds? thousands?) the former of which would be very vulnerable to malware.
The other option is you get one certificate from some acceptable trusted CA, or maybe you just mint your own, and then use that everywhere. This destroys privacy since trackers can just correlate the presented certificate.
There are also a whole bunch of environments where the secure web appears to work, but mutual authentication (the use of client certificates) does not work. In these environments the owner of the computers (which may not be the user) has authorised a middlebox HTTPS proxy. You can't do this with mutual authentication, you can find companies that are sure they have a solution, unless payment is conditional on the solution working rather than just being promised - at which point they'll remember they can't do it.
The reason this can't work is that TLS allows both parties to detect who they're talking to with mutual authentication, whereas in the usual single auth case only the client knows there is a middlebox. So to work around this you'd be reconfiguring Google's servers (as an example), not your computers, and unsurprisingly Google does not want that.
There is a third option: You keep a single master secret in the browser, and combine that with the identity of the site (e.g. the domain name) via a secure trapdoor function to create a unique per-site key pair which is then used for public-key authentication with only that site. The site-specific secret is easily recreated from the master, but without the master secret there is no feasible way to correlate two site-specific identities.
This is the approach used by modern (Hierarchical Deterministic) Bitcoin wallets. Older versions used distinct random private keys for every transaction, which as you say made key management rather painful. A single key which can be backed up once and used for any number of separate authentication channels is far more ergonomic.
Middleboxes are indeed a major problem for TLS mutual authentication. IMHO this would be a good reason to favor TLS client certificates for popular web sites—perhaps we could finally get enough pressure to see these MitM-boxes booted off the network.
Most of the current web browsers support it AFAICT:
* https://caniuse.com/#search=webauthn
The upcoming Safari 14 will add further support:
* https://www.theverge.com/2020/6/24/21301509/apple-safari-14-...
On a cleanup note, remember to check breach monitoring sites like https://haveibeenpwned.com/ and https://scatteredsecrets.com (creators of the FPGA-based cracking device).
That “or” should be “and” because a shorter password isn’t really useful even if you enable 2FA. I have seen websites that allow brute forcing TOTP tokens, so an on-site or low-latency attack could guess from 500k tokens (6 digit code with look-ahead time of 1 step) in 30 seconds, even if they change frequently.
I think that it’s time everyone used a password manager to generate really really long passwords. I set all passwords to 64 characters or the maximum allowable characters. There’s are some stupid businesses (hello, banks!) who have weird password requirements, like “more than 7 but lesser than 10 characters”. In such cases you’re better off with randomly generated passwords than a pattern you can remember.
> I set all passwords to 64 characters
This makes no real sense, if they aren't chosen randomly then having 64 of them makes little difference and might make things worse. If they are chosen randomly then you only need a couple of dozen and you're fine.
> I think that it’s time everyone used a password manager to generate really really long passwords. I set all passwords to 64 characters or the maximum allowable characters.
So, it's not long or random, but rather long and random.
That said, I'd advocate aiming for 96 to 128 bits of entropy - beyond that you just have a password that's tricky to type in, in cases where you cannot copy and paste (eg: boot password).
So for large and small letter, numbers and a handful (10) of special characters, that comes to 21 random characters (Log2(72^21)~129).
* https://tools.ietf.org/html/draft-ietf-kitten-password-stora...
If it becomes trivial to crack the passwords, then we're really left one factor. Unless we replace the password factor with something else.
Sqrl perhaps?
(Though password managers can help a lot.)
One of my banking apps has a 10 minute logout "feature" (which can't be disabled) that pretty much guarantees you need to have a crappy, easy to remember, password if you want to use it. Add on top of this a predilection for "2FA" (aka text message) every few times you log in and the thing is basically an unusable hot mess.
(looking at you walmart moneycard)
Here's what my site has on file for one of my own logins:
id: AWrNx4WDVIACFXeNDG4h6R6/ppUi8oIuXJYRwaJtOxssDZybQnu8wt6Cjdc4PqztvnSxnSgLmZGRT1BTnbZjz/M=
public key: pQECAyYgASFYIFsl5O6VHyqngNHPlNmWrjGTPjLFh1jzVnhOUJGP79yVIlgg6L2rDoH/l028WsMes+MbDU0RzM2oSdTcRq+cSwz/E/k=
friendly name: unhygienix
The only thing you can do with that data is the exact thing it's intended for, checking the user has the authenticator corresponding to that ID and wants to sign into this particular web site. Also I guess you maybe learn that this user enjoyed the Asterix comics?
You can't impersonate me using that data, any more than you can impersonate Hacker News based on the data inside its TLS certificate.
So just use passwords generated from 64-bit secret, and it's fine, no? Even xkcd's venerable 40-bit scheme is okay for now.
To go past 64,you'd want 11 characters.
Ed: and to take the pathological case of "classic" hashes, 50 billion guesses pr second - is (almost) equivalent to 36 bits of entropy pr second. If your password is 37 bits, on average it'll be found in one second - for certain in two.
If you want to aim for, say a hundred years (today), that should be about 32 bits (Log2(100 * 365.25 * 24 * 3600).
So 37+32 = 69 - which is about 12 random characters from an alphabet of 70, if my math is right.
Do note: random characters.
Still, a 50% to find in 100 years, 25% in 50, 12.5% in 25, 6.25% in 12.5... Still like 1 in a 100 passwords in just 3? years time. So if someone has millions of secure passwords [to crack ] ... You might want more entropy still [in the entire population] .
* https://tools.ietf.org/html/draft-ietf-kitten-password-stora...