Time-based One-Time Passwords With An Arduino

Get your feet wet with Time-based One-Time Password (TOTP) security by building your own Arduino OATH system. OATH is an open standard authentication system that provides a platform to generate tokens, making your login more secure than a password alone would.

The TOTP approach is what is used with many companies that issue hardware-based dongles for logging in remotely. This security may have been compromised but it’s still better than passwords alone. Plus, if you’re building it around an Arduino we’d bet you’re just trying to learn and not actually responsible for protecting industrial or state secrets.

The hardware setup requires nothing more than the Arduino board with one button and a screen as a user interface. Since the board has a crystal oscillator it keeps fairly accurate time (as long as it remains powered). It will push out a new token every thirty seconds. The video after the break shows that the Arduino-calculated value does indeed match what the test box is displaying.

13 thoughts on “Time-based One-Time Passwords With An Arduino

  1. OATH and TOTP in particular aren’t anything to do with RSA the company. The only thing in common is that the RSA SecurID tokens and OATH both implement a form of two factor authentication.

    The problem with the SecurID tokens was that somebody broke into the RSA servers and stole information. This doesn’t mean that all two factor authentication devices like this Arduino TOTP device have been compromised.

  2. I implemented Google authenticator into an arduino recently. This allows you to use the Google Authenticator app as a 2-factor solution with the arduino.

    I implemented a web service that required user,password,and Google Authenticator token to login and use the service.

    I’ll post some more info later.

    1. I just have to ask… You created a standalone hardware device that runs Google Auth to generate tokens… And you protected access to the tokens by requiring username, password, and… Google Auth token. 😝

  3. Expanding on what GotNoTime said:

    RSA stored information about the keys on their own servers as well as putting them on the keyfobs. This is bad security practice, as you want the key information to be stored in the same location as what it protects, therefore if anyone breaks in and gets the key, they’ve already broken in. Its as simple as RSA is dumb and they did not set their security model properly.

    1. pray tell how you think the 2fa service works?

      each fob has a fob ID,
      each fob has an individual seed value that is used to generate the time dependant code (from the seed value)

      at the other end the server has to determine the fobID (based on the source address, and username)

      and that the key sent is indeed correct.

      in order to know that the key code that is sent is correct, the seed value must be stored on the server along with the fob ID

      it’s not bad practice, it’s just how it works, and indeed could not work without it.

      try pulling you head out your anus and actually understanding what you’re talking about before making such ludicrous remarks!

      1. killr is 100% on the money. The RSA security model was a disaster, and the blame ends up at the feet of all OATH based systems that are not compromised. This project caught my attention precisely because it solves that very problem. Allow the users to set their own keys.
        If they fail to follow the instructions on how to generate true random keys, then that is their burden to bear.

  4. Yo, this looks great! We have a project on school like this. I would appreciate very much it if you could sent me the sourcecode! The link above doesn’t work anymore:)

  5. The link to the build is now, could use this right now. I need to do this to authenticate a device with a web service to make sure the web service hasn’t been duplicated. I’m building a GPS tracker prototype for my SXS as theft protection.

  6. The next thing to include in the lock, is a button from a smoke detector. That would provide a source for true random entropy. So on initial setup the lock could set a truly random key for the OATH process.
    This could eliminate tracking issues by using the OATH transaction only as ID, so the card only responds to a lock it already recognizes. The actual password could then be a one time PAD generated from the entropy source, and changed every transaction.

Leave a Reply to MCancel 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.