
All Your Passwords Are Belong to FPGA - walterbell
https://hackaday.com/2020/05/15/all-your-passwords-are-belong-to-fpga/
======
user5994461
>>> 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.

------
cj
> capable of 2.1 million bcrypt hashes per second,

Shouldn't this wildly depend on the bcrypt hash's work factor?

~~~
tialaramex
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.

------
dredmorbius
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.

------
rohan1024
Can anyone tell me why we do not have a mechanism like SSH keys to
authenticate to websites? Genuinely curious.

~~~
tastroder
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.

~~~
tialaramex
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.

~~~
nybble41
> 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.

------
walterbell
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/](https://haveibeenpwned.com/) and
[https://scatteredsecrets.com](https://scatteredsecrets.com) (creators of the
FPGA-based cracking device).

------
njsubedi
> 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.

~~~
tialaramex
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.

~~~
e12e
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).

------
throw0101a
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-storage-00)

~~~
dgellow
Or use bcrypt with a decent work factor, such as 10+.

------
jzs
"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?

~~~
Nerada
Cracking good (long) passwords is far from trivial (and mathematically should
remain that way), the main problem is most users pick terrible passwords.

~~~
amelius
The problem: users don't _want_ long passwords.

(Though password managers can help a lot.)

~~~
UncleEntity
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)

------
duck2
The boards have 4x Spartan 6 LX150, the same part in Pano Logic G2.

------
rini17
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.

~~~
e12e
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] .

------
libreverything
This isn't going to crack 100-200 characters passwords so this article is
pointless.

~~~
imtringued
How many passwords are that long?

------
arpa
I'm lazy and trust the local experts. What should be used instead of bcrypt?

~~~
indigo945
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.

~~~
contingencies
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.

