Monday 17 February 2014

Havig difficulties testing sites with 2 step authentication? Suffer no more!

We live in an era where the meaning of privacy - especially online privacy - is a vague, blurred thing waiting to be defined. We can never be 100% sure who, where and how is accessing our information. If we're lucky, the 3rd party's intentions are to protect us. To be honest, I don't feel as much aversion against sharing my life with Google and Facebook as many of my peers. I believe that as long as I benefit from what they gather... well, I don't have anything to hide. Really.

On the other hand, I strongly despise intruders who's acts on my account could very well raise suspicion over me without me actually doing anything wrong.
Fortunately more and more websites are introducing 2 factor authentication to prevent identity theft. While this will definitely not eradicate cyber crime, it might reduce it radically. I imagine people will less likely go into the trouble of getting access to my phone just to hack my email/facebook account if I'm not of any significance.

Since Google introduced TOTP into their login flow, many organizations using Google Apps made it mandatory for their employees. This however introduces extra complexity to the testing of tools and
services relying on Google login (or other social login flows) and people involved in test automation are facing a difficult challenge. Or are they?

What is 2 step authentiction?

Let's get couple of terms right with the help of Wikipedia:
The function of identification is to map a known quantity to an unknown entity so as to make it known. The known quantity is called the identifier (or Id) and the unknown entity is what needs identification. A basic requirement for identification is that the Id be unique. Ids may be scoped, that is, they are unique only within a particular scope. Ids may also be built out of a collection of quantities such that they are unique on the collective.

Authentication (from Greek: αὐθεντικός; real or genuine, from αὐθέντης authentes; author) is the act of confirming the truth of an attribute of a datum or entity. This might involve confirming the identity of a person or software program, tracing the origins of an artifact, or ensuring that a product is what its packaging and labeling claims to be. Authentication often involves verifying the validity of at least one form of identification.

Multi-factor authentication (also MFA, two-factor authentication, two-step verification, TFA, T-FA or 2FA) is an approach to authentication which requires the presentation of two or more of the three authentication factors: a knowledge factor ("something only the user knows"), a possession factor ("something only the user has"), and an inherence factor ("something only the user is"). After presentation, each factor must be validated by the other party for authentication to occur.

Two-step verification (also known as two-factor authentication) is a process involving two stages to verify the identity of an entity trying to access services in a computer or in a network. This is a special case of a multi-factor authentication which involves the presentation of two or more of the three authentication factors: a knowledge factor, a possession factor, and an inherence factor.

How does this translate to our life?

You might already be using this technique with your bank. Do you have a "token generator" device that you need to access your online banking platform?
Now days the "thing you own" often translates to your mobile phone, as that devious device became one of the few things that we all hang on to, even in our beds. Not to mention we discover the loss of it almost instantly. Did you know that we look at our phones 150 times a day on average?

I'll use Google as an example, but the same process applies for Facebook, Github and a whole lot of other services.

This results in the following flow:
Now I'm sure you see where the problem is when it comes to testing. While it's pretty easy to configure an automation suite to use a specific username and a password, waiting for a text message or using a smartphone app to come up with the verification code is indeed difficult and slow for the likes of most people involved in test automation.

So what can we do?

Fortunately people are not trying to re-invent the wheel as much as they used to, so most of the one-time password code generators work according to a very specific algorithm. Knowing this, it is not that difficult to come up with a generator of our own to support our testing efforts, and to bypass the second verification step just as quickly as a normal username-password screen.
I've been experimenting with this approach. For PHP, I've found a nice library that does everything you need, it's called (surprise): GoogleAuthenticator.

I wasn't as lucky with Java. There are many sort-of implementations, but I failed in finding a built for purpose library that I could easily use. So I've built one.

Using the Java library

All you have to do is to include the library with your favourite build tool from here.
Once the code is part of your project, simply use the following lines:

 GoogleAuthenticator ga = new GoogleAuthenticator();  
 String passCode = ga.getCode("your secret key");  

As you can see, it all comes down to knowing a second secret, which serves as a seed for the code creation process.

Acquiring the seed

The process is somewhat fiddly, but nothing to be afraid of. Here's how you do it:
Sign in to your google account if you haven't already, then in the top right hand corner, click on your profile picture, and select "Account".

 Select security settings:

 That will ask you for your password. Once through that, go for the 2 step verification settings and select "Move to a different phone"
Select the type of phone you have, and proceed.

This is the important part! 

You are now presented with a QR code that sets up Google Authenticator, and this is where the trick is. To acquire the secret, you need a barcode scanner (different to the Google Authenticator app itself). 
When you scan this QR code, you'll find a URL in it, which will look something like the one I've extracted from the picture above:
otpauth://totp/Google%3Ameza%40meza.hu?secret=xc6iavmpzqzgmljgpg5a4m2oarjys56c&issuer=Google
Do you see where I'm going to with this?
The URL has a query parameter named "secret", and the value is what you need to be able to generate the correct code.
Now there's one more important thing: open your Google Authenticator, scan this barcode and finish the steps with google. Failing to do that will lock you out of your account!

Other things worth mentioning:

  • Usernames and passwords are considered highly sensitive information. So is the TOTP secret. NEVER store these in a repository. Make sure you have a user specific configuration solution that allows individuals to set their own settings without the need to commit them.
  • You can now tell your developers how to implement their own 2-step verification process, and advise them about the necessity of doing so.

Updates

  • I've updated the library usage code, as I've made some changes to the interface.


2 comments :

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete

Note: only a member of this blog may post a comment.