Hackaday Prize Entry: Two Factor Authentication Key

Because people are generally idiots when it comes to choosing passwords — including people who should know better — Google created Google Authenticator. It’s two-factor verification for all your Google logins based on a shared secret key. It’s awesome, and everyone should use it.

Actually typing in that code from a phone app is rather annoying, and [Alistair] has a better solution: an Authenticator USB Key. Instead of opening up the Authenticator app every time he needs an Authenticator code, this USB key will send the code to Google with the press of a single button.

The algorithm behind Google Authenticator is well documented and actually very simple; it’s just a hash of the current number of 30-second periods since the Unix epoch and an 80-bit secret key. With knowledge of the secret key, you can generate Authenticator codes until the end of time. It’s been done with an Arduino before, but [Alistair]’s project makes this an incredibly convenient way to input the codes without touching the keyboard.

The current plan is to use an ATMega328, a real-time clock, and VUSB for generating the Authenticator code and sending it to a computer. Getting the secret key on the device sounds tricky, but [Alistair] has a trick up his sleeve for that: he’s going to use optical sensors and a flashing graphic on a web page to send the key to the device. It’s a bit of a clunky solution, but considering the secret key only needs to be programmed once, it’s not necessarily a bad solution.

With a small button plugged into a USB hub, [Alistair] has the perfect device for anyone annoyed at the prospect at opening up the Authenticator app every few days. It’s not a replacement for the app, it just makes everything easier.

The 2015 Hackaday Prize is sponsored by:

20 thoughts on “Hackaday Prize Entry: Two Factor Authentication Key

  1. Why the byzantine way of programming the key? It’s a HID device – just send it a HID message with the secret key. You can do the same to set the time.

    FWIW, there are commercial devices that do this already.

      1. Yep, the new(ish) Yubikey Neo’s even do U2F which is nice, no text box is needed, just chrome/chromium and a tap of an inserted yubikey. This acts the same (to the user) but wouldn’t really look as nice due to the text box.

  2. I hate it when someone provides their own custom authenticator app (looking at you Valve and Microsoft) instead of just supporting this standard. It’s not like they get any extra security by doing it. At least in the MS case they had the option buried somewhere as a fallback.

    I even came across one asshole that implemented the standard *exactly* except for using a different period length, deliberately making it incompatible.

  3. One, call it, disadvantage of the TOTP authentication code is the need for a secret per application/website. So unless there’s a way to select one of multiple entries in the device you would need such a USB device per application/website you’d like to use it for. One for accessing your Google, one for Facebook, one for GitHub…

  4. Note to self: if I steal a phone, quickly start up the browser and look for an Authenticator app. Changing the settings should give me extra time to cause havoc, buying stuff with stored credit card details etc.

    1. once you get past the lockout code, then if the owner is smart a second app lock like smart applock, then you usually need a password as well as the authenticator key, that’d be the two in two factor usually.

  5. “Because people are generally idiots when it comes to choosing passwords”

    I use the following when i need a secure password:
    $ dd if=/dev/random bs=32 count=1 2>/dev/null | xxd -c 32 -u -ps
    7BBC69D0FEEFA632FDA2ACFB4A4976A0E384142125CA6032E58D41AA0572F4CF
    It may only be hexadecimal, but 256 bits or 1.16×10^77 combinations makes me happy.
    Most of the time I get error messages that 64 character passwords are too long

    I store the passwords in a encrypted file, which is secured with a pass phrase.

    1. I just use KeePass. Key length is selectable, selections available for spaces, special characters, high ASCII, even “user each character at most once” or “leave out lookalike characters” if you need to write the password down for some reason. And, hate to tell you, but my 32 character password has roughly 223 bits of entropy (yes, it estimates that too). So the most I have to deal with is a bank telling me “your password isn’t long enough” when they really mean “wtf is this strange unicode crap like æƣɛ?”

      The database of passwords is encrypted with, in my case, both a key file and a passphrase. But I keep the database stored in a ‘private’ cloud access so every device I own can keep all the passwords synced up

    2. While 64 characters is nice and secure, the fact that you only use uppercase hex actually reduces the number to about 2.1×10^71 possible combinations; which would still take forever to brute force, but, generating all of your passwords in the same manner means an attacker can make assumptions about all of your passwords.

      Why not just use a memorable passphrase for each password? Uses full alpha, and you can throw in some special characters as well, which greatly increases the character set and therefore the number of possible combinations. And you don’t have a single point of failure with all of them in an encrypted file, which you already use a passphrase on.

      1. Oops. /me eats hat You’re right, its about 1.2×10^77 combinations. I just noticed I did my math wrong.

        I still suggest using a passphrase, easier to remember, no single point of failure.

  6. While it’s a nice application of AVR programming, it’s really not necessary anymore (or will not be in the near future).

    I urge everyone to embrace FIDO U2F (Fast IDentity Online, Universal Second Factor)! Same USB stick form factor (optionally even smaller), available right now, as cheap as ~5–10 units of currency (dollars, euros, pounds, all pretty much the same), but come with a proper secure smartcard controller.

    Authentication is with elliptic curve signatures, and, partially in response to Chris, the best thing is: can be used with an unlimited number of websites. The device has an internal secret that it will never export, and re-creates a website specific key based on ID information from the website on the fly, each time. No storage per website is needed.
    Bonus feature: If supported by both ends, the U2F authentication will also authenticate the TLS ephemeral channel parameters, providing man in the middle protection.
    The only sour point right now is browser support: Since this is slightly more involved than pure HID keyboard entry, the browser needs to access the USB device directly. Currently only Chrome can do that (on all three platforms). This should clear up soon enough, since in addition to Google also Microsoft is a member of the FIDO alliance.


    Henryk Plötz
    Grüße aus Berlin

  7. I don’t see a need for a dedicated USB key. I make a Google Authenticator clone for Pebble called QuickAuth. This saves a few second instead of opening your phone but even with me using it to connect into work, I used it 2-3 times a day. Not exactly a big saving. Having a USB key plugged into my laptop (which people won’t remove) removes the security. You might as well have an app running which copies the latest key in every time F12 is pressed.

    1. There’s obviously a significant difference between this and an app: the device only response to external user input, and keeps the key material on an external device, so a compromised computer can’t force it to divulge an OTP, or obtain the key off it.

    2. The benefit I see is that you can take it with you. Authenticate for the various services used while at work, pop out the key when you head home and use it there. On vacation? The authentication device is on your keyring and you can use unknown systems without worrying about exposing your password.

Leave a Reply to pelrun Cancel reply

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