Two-factor authentication key fob

I need to add two-factor authentication to one of my organization's websites, but all the key fob solutions that I could find involve steep monthly fees. This is for a mobile website, so things like SMS and other "soft" tokens won't work.

Has anyone ever come across an Arduino implementation of an OTP key fob? Something like this? http://www.tokenguard.com/images/tokens/SID700.gif

I imagine it would have to be a very small circuit, with a very small monochrome display plus a button to activate.

Does anyone have any thoughts or recommendations on where to begin looking into something like this?

(I'm focusing more on the hardware side for the moment, there seem to be some pre-existing libraries for the software side of things)

Thanks!

I imagine those devices only work when paired with their proprietary software on the webserver.

If so, then you would not only need to make a physical Arduino device but also the secure web server software that goes with it.

That sort of security stuff is far above my pay grade - I suspect that is why the commercial systems are expensive. After all, they would not be much good if one of us Arduino hackers could make one.

...R

If you're hoping to use the existing fobs out there I think you'll have trouble getting access to the exact algorythm that they're using.

If you are creating your own fobs then you could duplicate the functionality fairly easily. Each fob would be given it's own ID before being given to the client. (this id would be held in EEPROM).

The controller chip then just has to use this as a seed (along with the current time) to come up with a number.

RSA Encryption algorythms are fairly easy to implement and are well documented on the web. These could be shoehorned into the task.

All you'd need to keep track of is which fob each user has. When a user logs in, their fob id would be retrieved from the database. Using the same algorythm the server could then calculate what the users fob should be giving them. Just to be safe it could also work out what it was showing a minute ago and what it will be showing in a minutes time. If any of these numbers match the users input, then it's a go.

For sure, totally agreed. Right now, just as a proof-of-concept, I'm trying to figure out how to create a small device that can be fit onto a keychain, have a coin battery, and as small a display (lcd monochrome) as possible.

Oh and just as a nifty little extra feature. The ones I was using years ago had two buttons. Both were unmarked. The one on the left would show a response, the one on the left would show the same response with the digits arranged backwards.

In the event that the user puts in the reversed response it would allow access BUT flag up that the user is acting under duress. This allows security to be silently deployed.

Ken, love that feature.

including the industry-standard AES algorithm.[/quote] There is nowhere in the standard AES algorithm specificiations that mentions how the current time is incorporated into a code. I'm pretty sure RSA are not going to disclose that information lightly. They'd rather sell their own product.

There's a big difference between using an "industry-standard algorithm" to giving away the full details of how their implementation works.

All good points :-)

Forgetting about the algorithm for a second, does anyone have any thoughts on the hardware?

Thanks!

https://www.kickstarter.com/projects/1516846343/microview-chip-sized-arduino-with-built-in-oled-di

I believe the MicroView is being manufctured by sparkfun for the original designers .

..looks interesting, but would need further research.

@AnalysIR That looks like an incredible bit of kit. Maybe a case that includes a lens to see the output more clearly.

I'd say the biggest hurdle to overcome is to find a display that is both very small and easy to drive. Just about any microcontroller would be capable of the rudimentary maths involved in coming up with the users passkey. The issue is that you want to be able to fit the whole package into a simple little gizmo that'll fit in the pocket. (or ideally, on a keyring).

Once you've found a source for your display the rest is easy.

osmosis311: Forgetting about the algorithm for a second, does anyone have any thoughts on the hardware?

How do we know you are not trying to develop this to perpetrate a fraud?

...R

@Ken: agreed

@Robin: as in, replacing someone’s device with a counterfeit? Not sure how me making my own device could defraud anyone…

I work with a volunteer ambulance service, and I designed all of our computer systems. I’m trying to add security so that we can ensure that our patient records are kept as secure as possible when accessed over the web.

osmosis311: I work with a volunteer ambulance service, and I designed all of our computer systems. I'm trying to add security so that we can ensure that our patient records are kept as secure as possible when accessed over the web.

In which case, each volunteer should have a unique device so it can be disabled (essentially ignored by the website) when they lose it.

Yes

I'm trying to add security so that we can ensure that our patient records are kept as secure as possible when accessed over the web.

The reason organisations use the 'expensive' fobs etc is because they have a 'quality' audit trail (= acceptable answer), when the question is asked - [u]when/u the system is compromised. And probably because they are reasonably good.

Contrast that with the alternative...."We are very sorry our patients info was compromised...but rest assured, we use a very good DIY solution for the important bits of our internet data security.

:(

In this neck of the woods, you would be required to have a data protection person, who would have to sign off, that the data security aspect was acceptable and inline with legislative requirements.

However, if there is no budget for this, DIY is better than nothing.

osmosis311: I need to add two-factor authentication to one of my organisation's websites, but all the key fob solutions that I could find involve steep monthly fees.

What's wrong with a Yubikey?

No monthly fees.

osmosis311: I work with a volunteer ambulance service, and I designed all of our computer systems. I'm trying to add security so that we can ensure that our patient records are kept as secure as possible when accessed over the web.

This may indeed be true. But it would also be a very good reply from a fraudster.

...R

Robin2:

osmosis311: I work with a volunteer ambulance service, and I designed all of our computer systems. I'm trying to add security so that we can ensure that our patient records are kept as secure as possible when accessed over the web.

This may indeed be true. But it would also be a very good reply from a fraudster.

...R

Robin, I'm not seeing the opportunity for fraud here - you could certainly build something that would function like RSA's securID or other vendors products, but without the proprietary detail of their encryption method (which would not be forthcoming), such a device would not help you crack systems defended by it.

wildbill: Robin, I'm not seeing the opportunity for fraud here - you could certainly build something that would function like RSA's securID or other vendors products, but without the proprietary detail of their encryption method (which would not be forthcoming), such a device would not help you crack systems defended by it.

There are many ways to perpetrate a fraud. I am not an expert therefore I am cautious. For all we know the whole purpose of the exercise is to gain access to the patient records by pretending they are secure. And it may have nothing at all to do with ambulances or patients. "That man has tricked Grandma out of all her savings and those fools on the Forum helped him"

...R

Guys, these fobs are OTP (One-Time-Pad) devices. No encryption. AES is irrelevant. It’s a bunch of pre-shared keys. A secure server generates a few thousand (or more) 6-digit PINs, keeps a copy of the list for itself, and puts a copy on the key fob.

When the user authenticates, they put in their password (one factor), and a PIN from their fob (second factor). Each time the button on the fob is pressed, the next PIN is sequence is displayed. The server has been keeping track of the last successfully used PIN, so will only accept the next, next+1, and next+2 PINs in the sequence (if a valid but out of sequence PIN is received [meaning it’s probably an attacker’s guess], the attempt is rejected). (This also means you don’t sit there pressing buttons on your fob because you will get out of sync with the server and get locked out of your account. Usually, a secure method of re-syncing the fob’s current PIN with the server is allowed for inadvertent button presses.) One you’ve used up all your PINs, the fob is useless until reprogrammed with new PINs.

At attacker obtaining the physical fob (one factor) is little danger unless he also beats the password out of you with a rubber hose (both factors).

OTP is reasonably secure, even a DIY implementation*, as long as your other factor (password) authentication is also secure. I.e., don’t allow short/dictionary passwords. Also be sure to lock the account after 3 unsuccessful password or OTP attempts to reduce brute-force attacks.

  • In an Arduino scenario, you’d be storing the PIN sequence in PROGMEM flash, storing a pointer to the current PIN in EEPROM, and burning the fuse bits to prevent readout of flash and EEPROM. Secure the PC used to generate the PINs and flash the Arduino as it is a weak link in the chain. This is where commercial companies make their money – their solution is end-to-end secured, audited, and tested. Yours has holes, but they are small holes.

As for hardware, you just need to find a tiny enough LCD+driver and go to sleep, waking on interrupt when the button is pressed.

EDIT: for a display, consider the HP QDSP-6064 bubble LED as sold by Sparkfun. The display only has to be lit occasionally, so battery life should be acceptable. It’s only 4 digits, but that may be enough for your purposes. Or stack two displays for up to 8 digits.