Multi Factor Authentication (MFA) has become popular during the last months even in the non tech-savy user base. On the one hand this is due to an increase in media attention: reports on bad password leading to breaches as well as advising people to improve their personal security in a “we listen to all of your communications / NSA-GCHQ” world thing. On the other hand the security industry has been singing the “usernames and passwords are dead” song for quite some time. Recently I stumbled on a joke (sorry - I can’t recall who told it):

“They do have two factor authentication - Besides a username you also need a password!”

Funny, true and very . . . but, what are the possibilities to improve the situation?

The proposed techniques for MFA vary from smart cards to RSA-token generators to apps on your mobile phone or tablet. Basically we end up with two different mechanisms for generating an One Time Password (OTP) which are implemented in various ways and forms: You always need some sort of event for triggering the OTP generation. This can either be a counter (HOTP - RFC 4226) or the actual time (TOTP . RFC 6238). One may add some serious cryptography on top like private / public keys. To get the system working completely we need a client (your smart card, mobile app, etc.) and the server you want to log into. If we assume the simplest approach to implement a MFA solution you would run the same code generating the OTP on the client and the server side. Make the user enter the OTP generated by the client and compare it to what you calculated on the server. There is nothing wrong with this approach. It works well in event/counter based and time based mode.

However, after a certain while you will realize that client and server are not in sync anymore. There are various ways and protocols to synchronize the two algorithms. Again, the simplest way is to generated not only one OTP but several on the server side and compare these to the one provided by the user. Assuming you are using the time based mode, your server calculates the OTPs for a few time steps before and after its current time to allow the client to have a slightly different time. Of course this window weakens your security posture to a certain point. But given the lifetime of such an OTP which is in the order of 30 seconds and its length (6+ digits) it will still be vary hard for an attacker to mount a guessing attack against your MFA. Besides classical protections against brute force attacks like tar pits should be implemented anyway.

The open authentication initiative (OATH) takes these approaches a little step further. Their work includes an additional challenge response scheme (RFC 6287) for multi factor authentication. I am curious, so far I haven’t seen any one implementing a zero knowledge based challenge response scheme in combination with OTPs.

Besides the classical web-flow use case: Think about GMAIL

• accessing your emails with an username, password and an OTP generated by an app on your mobile device. What are other flows or scenarios where you could use an TOTP or HTOP mechanism? And let’s assume for a moment that we are not bound to a four to six digit one time password anymore, but could use something like 16 BASE64 characters or more.

(1) A friend of mine started an interesting project about Single Packet Authentication on the Web - in short: WebSPA. Simplifying his idea: You make an request to an URL containing enough authorization information as well as command information to start a service like ssh on your box from a browser. Besides not containing any information as clear text you need quite some randomness and some way to limit the “lifetime” of such an URL. Here we are - OTPs within an URL… You’ll find his work at: WebSPA.

(2) Why not using it for machine to machine communications? The computational overhead is very limited - otherwise it would not work on mobile phones ;). No seriously, there is some overhead - but it is acceptable and would relieve you from all the pain of changing passwords for technical users. By the way - did you ever do such a thing? It’s painful !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! So? Let’s skip static passwords for technical users and move on to OTPs instead.

(3) Keys for signing requests (HMACs) could as well be generated from OTPs. This would give a per request authentication with a key different for each request. Of course you would need way more than the classical four to six digits and not only digits. But the above described mechanics simply produce a byte array of the length determined only by the hashing algorithm you use and your choice of truncation.

Given the ideas 2 and 3 one has to figured out a clever way for synchronizing the communication partners in case they loose each other. In a very simple manner one could set up a special web service based on pinned certificates to sync the counters / time stamps. And I am pretty sure there are other ways besides costly PKI to fix this condition.

So far, so good. I am sure, there are many more scenarios to employ multi factor authentication besides human-machine interaction. Think about it - let me know…

Cheers!