Build Your Own Two-Factor Authenticator With Good USB

Two-factor authentication is becoming the norm for many applications and services, and security concerns around phone porting hacks are leading to a phaseout of SMS-based systems. Amidst that backdrop, [Josh] developed his own authentication device by the name of Good USB.

The device can be built using a Arduino Leonardo, SS Micro, or even a BadUSB device. It’s the latter which [Josh] most liked, and since the nefarious device is being repurposed for good, it led to the name Good USB. Basically any Atmega32U4-based device will work, as the key functionality is the ability to emulate a USB keyboard to a host PC.

Using the device is just as simple. With the Good USB plugged in, one simply needs to click a button in the companion app to generate a code for the given account you’re logging in to. Pressing the button on the device then types in the code for you. Alternatively, if your device has no button, it can be set up to simply type the code two seconds after you select an account in the companion app.

The code is on Github for those wishing to make their own. Caveat for the cautious: it’s still a work in progress, and there may be security holes in the current implementation.

If you’re interested in the nuts and bolts of how 2FA works, we’ve looked into that in detail. Video after the break.

19 thoughts on “Build Your Own Two-Factor Authenticator With Good USB

      1. In 1996 the large company I worked for supplied employees who had to work remotely with a small device about the size of a pager that supplied a six digit number that changed every minute. To sign on to the company network you needed user name, password and the current six digit number displayed. Sorry but I can’t remember the name of the device. Several financial institutions have apps that similarly provide a changing number that is required to sign-in to their web site.

        All systems that require a physical object are subject to theft. Especially cell phone systems. I know personally of instances of cell number theft which seems to be a particularly weak spot, especially if there is an unscrupulous employee in a local cell phone store.

      2. The company I worked for in 1996 gave employees a fob with six digit numeric LCD screen that changed every minute. To sign-on to the network you needed username, password, and the current employee specific six digit code. Financial institutions have phone apps that generate the required six digit code every minute. The main weakness of physical second factors is theft. It seems a biometric “who you are” is needed for security. Then you just have to worry about insiders or hackers with access to the security system.

        I know personally of the theft of cell phone numbers by unscrupulous cell phone store employees. And there is also SIM card theft.

      3. That’s the issue.

        Factor 1: password
        Factor 2: the same password, but stored on a device

        That’s not a second factor, it’s an alternative to the first factor. To be a second factor (something you have) you’d have to *not* be able to just copy the contents of this device to another device and use it the same way. You have to uniquely identify that you “have” a specific and unique physical thing. This is (part of) what FIDO2 keys do, they aren’t just password stores.

        1. Manually enter in part of the password, the rest of the password is on the device. Probably not as secure as proper 2FA, but it allows the use of much longer passwords than would otherwise be practical, without requiring specific support from the application.

          1. Then just save (or have the credentials intercepted) and you can recognize it as a simple username+password Auth. Fido tokens generate a digital signature on session data, so you can’t reply a previous session.

    1. As far as I understood this is more like a TOTP generator, so you don’t need to type the code manually. But I am not sure if I understood this correctly and how much I would call this “2FA”. anyway I think yubikey etc. have this functionality as well iirc.

    2. The first factor is your password. The device generates the second factor, a time-limited authentication code. The device stores a private authentication seed and not your password. It’s similar to an RSA SecurID token except it handles multiple accounts. The app just tells the device which account for which to generate the code.

  1. “With the Good USB plugged in, one simply needs to click a button in the companion app to generate a code for the given account you’re logging in to. Pressing the button on the device then types in the code for you.”

    Anyone know how the companion app hands the code over to the usb device? cant find this info anywhere and i have a hunch that its going to be where the security fails.

    1. I think he hardcoded into the loaded executable.
      He mentions he could potentially use the efuses to restrict access, but has not done that as yet.

      I’m seriously considering doing this, or something similar. I’ve got a laptop to work from home and I need to key in a code multiple times a day. (In an otherwise secure environment).

      Load an encryption code into ram; decrypt the key for usage; reload the encryption key if the power fails.
      If you unplug the laptop and device to steal it, the encryption key is lost from the device and the one time code is inaccessible.
      (Laptop is plugged into a monitor/dock; unwieldy to not unplug it).

      If I were worried about more security, then I’d be concerned somebody would have to wait till I was logged in, take me out, and gain access then.

    2. According to the linked article, the companion app just tells the device for which account to generate the authentication code. The secret seed is stored on the device not the companion app. The device generates the code done entirely within the device and then “types” the authentication code.

  2. Yes I think the original writeup does not treat the 2FA implementation at all, except mentioning that Arduino TOTP library in the very end. A bit poor documentation but a great project, and I learned through this about the totp rfc. Cool

Leave a Reply to PasserbyMcGeeCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

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