All Your Passwords Are Belong To FPGA

When used for cracking passwords, a modern high-end graphics card will absolutely chew through “classic” hashing algorithms like SHA-1 and SHA-2. When a single desktop machine can run through 50+ billion password combinations per second, even decent passwords can be guessed in a worryingly short amount of time. Luckily, advanced password hashing functions such as bcrypt are designed specifically to make these sort of brute-force attacks impractically slow.

Cracking bcrypt on desktop hardware might be out of the question, but the folks over at [Scattered Secrets] had a hunch that an array of FPGAs might be up to the task. While the clock speed on these programmable chips might seem low compared to a modern CPUs and GPUs, they don’t have all that burdensome overhead to contend with. This makes the dedicated circuitry in the FPGA many times more efficient at performing the same task. Using a decade-old FPGA board intended for mining cryptocurrency, the team was able to demonstrate a four-fold performance improvement over the latest generation of GPUs.

An earlier version of the FPGA cracker

After seeing what a single quad FPGA board was capable of, the [Scattered Secrets] team started scaling the concept up. The first version of the hardware crammed a dozen of the ZTEX FPGA boards and a master control computer computer into a standard 4U server case. For the second version, they bumped that up to 18 boards for a total of 72 FPGAs, and made incremental improvements to the power and connectivity systems.

Each 4U FPGA cracker is capable of 2.1 million bcrypt hashes per second, while consuming just 585 watts. To put that into perspective, [Scattered Secrets] says you’d need at least 75 Nvidia RTX-2080Ti graphics cards to match that performance. Such an array would not only take up a whole server rack, but would burn through a staggering 25 kilowatts. Now might be a good time to change your password to something longer, or finally get onboard with 2FA.

We’ve covered attempts to reverse engineer hardware designed for cryptocurrency mining, but those were based around application-specific integrated circuits (ASICs) which by definition are very difficult to repurpose. On the other hand, disused FPGA-based miners offer tantalizing possibilities; once you wrap your mind around how they work, anyway.

[Thanks to Piejoe for the tip.]

21 thoughts on “All Your Passwords Are Belong To FPGA

  1. Two Factor Authentication is nice and all.
    But it has downsides when every website wants its own app…

    Would be nice to bake it into Email in a standardized way.
    So that one can just give one’s email, then have the website/service send one a confirmation email that one uses a link in to log in.

    It’s not like Email already is the single point of failure for accessing nearly everything one does on the internet. So adding this functionality wouldn’t make thing any worse. (And then one practically only has one password to remember, and that is to one’s Email, and that can then be a fairly long password. (Like CorrectHorseBatteryStaple is just a casual 25 character easy to remember password that absolutely no one should use.))

    1. What website have you used that wants its own app? Even Google will let you use another app instead of their own Google Authenticator. Snapchat, Github, Google, Reddit, Discord, Twitter, npm, TeamViewer, Microsoft, Cloudflare, Gitlab, Instagram, and Amazon were all 100% okay with using Authy even though several of them have their own app.

      1. It would be nice if it were handled by the Email service.

        So that registration and login in is just an Email, the website then just sends a request to your Email service, and the email service then relays it to your app of choice.

        The request never actually drops into your inbox as an Email.

      2. Steam wants you to use its own app. It makes it a royal PITA to get hold of the key (iirc involving a jailbroken ios/android device), as well as using a slightly different algorithm for some reason

    2. There are really only 3 2fa apps out there if they don’t use one of them then they usually use text message. Also email would severely impacts the effectiveness of 2fa. The whole point is to have a single 2fa point ie your phone; you can log into email anywhere.

    3. Secure implementations of 2fa require 2fa to reset passwords, meaning email is no longer a single point of failure. Your proposal additionally has the issue that it trains users to click on links in emails

      1. That is indeed a downside. And why I said “Would be nice to bake it into Email in a standardized way.”
        Ie, you don’t get it as an Email in itself

        But rather, your Email service provider knows that messages of a certain type should go to their/your two factor authentication app instead.

        This then means that one doesn’t need to hassle with setting this thing up more than once.
        All a website registration suddenly needs is an email address, they send the authentication to the Email service, that then relays it to your app of choice, that you then answer and the thing works back on the chain to the website, letting them know that you are in fact who you state that you are.

        Ie, registration and login is suddenly just an email address, and accepting it in an app of your choice. The website has no clue what 2FA app you use, they just need to know your email, the rest is handled from there.

        Links in email is abhorrent as a solution, that I can agree with.

    4. What you are proposing is not 2FA, it defeats its purpose.

      The purpose is not to ask for a second confirmation, it is to use a second channel, independent of the first one.

  2. xkcd’s 936 is still memorable and even secure after all these years, so even the FPGA might move on and look for a weaker target. Locks keep the honest people out — for a little while.

  3. Hmm, so if I find a digital wallet on a discarded USB and it has some unclear number of Bitcoins I might be able to find out how many ?
    Or even go further and break the encryption and see where it is in the transaction history audit trail ?
    Or even snatch it, is there a good forum web site that touches on this with any pertinent details ?

  4. I guess these logins do not have lock out after three failed attempts? That would render most of this useless in less than a millisecond I would think and alert the user that some dbag is trying to unethically enter their account.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.