All Your Passwords Are Belong to FPGA(hackaday.com)
hackaday.com
All Your Passwords Are Belong to FPGA
https://hackaday.com/2020/05/15/all-your-passwords-are-belong-to-fpga/
12 comments
This isn't going to crack 100-200 characters passwords so this article is pointless.
How many passwords are that long?
I'm lazy and trust the local experts. What should be used instead of bcrypt?
In couple years that will be also no big problem to crack with enough cheap FPGAs from today. Think about Kintex-7 boards for couple hundred dollars from AliExpress.
SCrypt is specifically designed to be hard to crack using FPGAs. To achieve this, it relies on high memory requirements for calculation of the hash. Crypto-mining boards for traditional cryptocurrencies have no memory requirements, and therefore cannot be repurposed to calculate SCrypt. However, with the advent of cryptocurrencies that also rely on memory-inefficient hash algorithms in order to prevent people from using classic FPGA clusters to mine them professionally, this is likely to change, as now there is monetary incentive to develop FPGA boards with high amounts of memory. The situation is still less bad though.
Memory is really cheap, so I wouldn't base any decision on the current public market for these devices. You can definitely get an FPGA board custom designed, debugged and delivered within two weeks in China.
Argon2 is the obvious contender
As others have mentioned, scrypt and Argone2. For general overview, see:
* https://tools.ietf.org/html/draft-ietf-kitten-password-stora...
* https://tools.ietf.org/html/draft-ietf-kitten-password-stora...
"Now might be a good time to change your password to something longer, or finally get onboard with 2FA."
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?
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?
Client certificates is also a thing.
And they are an utter PITA to use, everywhere in the stack...
We could fix that..
Cracking good (long) passwords is far from trivial (and mathematically should remain that way), the main problem is most users pick terrible passwords.
The problem: users don't want long passwords.
(Though password managers can help a lot.)
(Though password managers can help a lot.)
Oh, the irony...
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)
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)
If it’s trivial to dump password hashes, you’re probably already left with zero factors.
For a lot of things this is true, but not for WebAuthn.
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.
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.
Not trivial. You still have to break in and get /etc/passwd or the equivalent, right? And doesn't creating a unique salt for each client also help significantly?
WebAuthn is well supported across all major browsers and can be used for multifactor login without username and password.
Can anyone tell me why we do not have a mechanism like SSH keys to authenticate to websites? Genuinely curious.
As arpa mentioned in the other thread, client certificates are a thing. Outside of corporate infrastructure the implementation is somewhat painful though and OS/browser sides far from optimal in terms of user experience.
Cryptographic certificates bind a key to an identity. But, that's not really what we want in this scenario (notice how your SSH keys aren't bound to an identity) so immediately alarm bells should be going off.
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.
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.
> One option is each site you authenticate to needs to issue you a certificate for your identity on that site. … 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.
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.
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.
Yes, and browser vendors have refused to enhance support for this. To be fair though, client certificates have some obvious downsides, before all that you only have them on the device where they have been created. Since most people use several devices (desktop/notebook/tablet/phone) throughout the day, you require some way to keep them in sync. Cloud services could solve this, but tend to be vendor-specific, and doing it by hand via sneakernet is painful. Then this same problem occurs all over again if a certificate is leaked, for example due to device theft, and the cert needs to be revoked and replaced.
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.
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.
> Since most people use several devices (desktop/notebook/tablet/phone) throughout the day, you require some way to keep them in sync.
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.
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.
I’m hoping that at some point in the future that’s what password managers will become, client certificate managers.
When you are trying to login to iCloud or AppleID homepage from Safari on iOS, the OS asks you if you’d like to authenticate to the website using the iCloud account that is currently added on that device. So we have that tech, but I think the browser vendors need to do some work to support what you’re asking for.
WebAuthn does this pretty much.
* https://en.wikipedia.org/wiki/WebAuthn
Most of the current web browsers support it AFAICT:
* https://caniuse.com/#search=webauthn
* https://webauthn.io
The upcoming Safari 14 will add further support:
* https://www.theverge.com/2020/6/24/21301509/apple-safari-14-...
Most of the current web browsers support it AFAICT:
* https://caniuse.com/#search=webauthn
* https://webauthn.io
The upcoming Safari 14 will add further support:
* https://www.theverge.com/2020/6/24/21301509/apple-safari-14-...
On a positive note, iOS14 will enable website 2FA via WebAuthn & TouchID/FaceID.
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).
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).
The boards have 4x Spartan 6 LX150, the same part in Pano Logic G2.
Looks like the setup can guess any 32bit bcrypt-ed secret in reasonable time.
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.
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.
So for a random password picked from 72 character alphabet (capital/regular letters, 0-9, 10 punctuation chars) - 5 characters would be too short, but 6 might be safe? (log2(72^5) < 31, log2(72^7) ~ 37).
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] .
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] .
> Now might be a good time to change your password to something longer, or finally get onboard with 2FA.
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.
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.
On the server side you can do WebAuthn and not care about conventional passwords. At that point you don't hold any secrets at all, you could actually publish the credentials you hold on file and there's only a modest impact on user privacy and no impact on credential security.
> 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 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.
Somewhat uncharitable reading of gp (unless there was an edit):
> 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).
> 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).
>>> Each 4U FPGA cracker is capable of 2.1 million bcrypt hashes per second, while consuming just 585 watts.
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.
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.
Is there a table or chart of password crack rates vs cost over time, say, to the mid-to-late 1990s or before?
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.
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.
> capable of 2.1 million bcrypt hashes per second,
Shouldn't this wildly depend on the bcrypt hash's work factor?
Shouldn't this wildly depend on the bcrypt hash's work factor?
You are correct, and in the source post we find it assumes work factor 5 (32 iterations) whereas the same source says most web sites choose between 7 (128 iterations) and 14 (16384 iterations).
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.
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.
Time to move to Argon2 and/or scrypt?
* https://tools.ietf.org/html/draft-ietf-kitten-password-stora...
* https://tools.ietf.org/html/draft-ietf-kitten-password-stora...
Or use bcrypt with a decent work factor, such as 10+.