It is unfortunate that talking about security is still deemed dangerous. The idea is that if you do not share the information it will be harder to find the security hole. The opposite is true as well. By not talking about how things work, people start assuming. This inevitably leads to many problems and is often the start of many security problems that go undetected.

Let’s have a look at a very concrete example.

Two-factor authentication

Not so long ago, the one and only barrier grant someone access to an application was the typical “user and password” strategy. The basis behind the idea is solid. Provide the user with an identification tag or userid and use an out-of-band method to share a password. The combination of the two will grant the user access. Obviously, there are some questions that might arise:

  • Which userid should we use?
  • Which out of band method do we use?
  • What if the user losses the passwords?
  • What if the password is easy to guess?
  • What if the password is shared?

Many of these are known for a long time and for most of them have some form of solutions have been implemented. There are password policies forcing a certain complexity, expiry of passwords, reset strategies, one-time passwords, just to name a few.

Unfortunately, social hacking is very popular and the coronavirus has forced many people to work from home making the potential target for hackers substantially bigger and easier. Many passwords will simply be shared by phone or email on simple demand.

So, can we do better?

Two-factor authentication

The idea to improve security has been around for a while and is really simple to explain. Don’t just use something the user knows, but also use something the user owns. In broad terms, this is referred to as two-factor or two-step authentication. As the name says, we are using two ingredients to authenticate. So every user(id) is linked to a password and something a user has.

What does the user always have? These are small tokens that people carry around. Although the idea of tokens has a fair share of followers for most small companies, the management and maintenance of the tokens are too cumbersome. Fortunately, there is another way.

Thanks to the smartphone rise of recent years, most of us are carrying around a small computer. A simple app can, based on a pre-shared secret and a timestamp, generate a one-time number that changes every minute. To authenticate the server will calculate the number and match it with the number that is provided by the user and in combination with the password check grant access.

The result is that a lost password does not have any impact on security. Assuming that stealing a mobile phone is quickly detected – an assumption we can all agree on – makes for much-hardened security.

So how does this token-generator work? Let’s investigate one of the most popular token generators, Google Authenticator. To start you will either have to enter a shared key or scan a QR code. Obviously scanning a QR code is the simplest method as most mobiles come with a camera. The code that is entailed in the QR code is generated by the authentication system and stored with the user profile.

The calculation of the short-lived authentication code is strictly defined. A small Perl program demonstrates how the 6 digits are calculated:

#! /usr/bin/perl

# function GoogleAuthenticatorCode(string secret)

# key := base32decode(secret)

# message := floor(current Unix time / 30)

# hash := HMAC-SHA1(key, message)

# offset := last nibble of hash

# truncatedHash := hash[offset..offset+3] // 4 bytes starting at the offset

# Set the first bit of truncatedHash to zero //remove the most significant bit

# code := truncatedHash mod 1000000

# pad code with 0 from the left until length of code is 6

# print code

# See : source

use MIME::Base32;

use Digest::HMAC_SHA1 qw(hmac_sha1_hex);

my $secret = ‘TESTTESTTESTABCE’;

my $key = decode_base32($secret);

my $msg = pack(‘H*’, sprintf(‘%016x’, int(time()/30)));

my $hmac = hmac_sha1_hex($msg, $key);

printf(“%06d\n“, (hex(substr($hmac, hex(substr($hmac,-1,1))*2, 8))&0x7fffffff)%1000000);

As you can see, there is no magic behind these strangely changing numbers but straight forward mathematics. Obviously, the secret specified here needs to be the same secret as is entered in your Google Authenticator. Admit it is fun to see your computer calculate the exact same number as your Google Authenticator is showing on the screen once you have entered the secret in the app.

Danger!

Things start to be more dangerous if people trust these “not-so” magic numbers too much. If you do not understand the process of calculating these numbers, you might believe that they are the “better” part of the authentication flow. No one would possibly be able to guess this number, right? Well, that is absolutely not the case. A strong password is the first barrier to a good security policy. Adding the “something you have” Google Authenticator to it improves the security even further. But just relying on Google Authenticator as the sole source of authentication is a very bad choice.

With security comes complexity. Only seldom can complexity be reduced without lowering the security level. And this is exactly what is happening if you cut the basic “password” rule out of the scenario just because it is to complex and with the wrong concept of the “Google Authenticator” being a replacement.

Conclusion

It is a very unfortunate situation that due to bad communication and difficult to understand technical documentation additional security measures are assumed to replace original ones. Security often comes with a layered system. Each layer adds security at the expense of complexity. Some layers can be interchanged with other similar layers but care has to be taken to not undermine the entire system by eliminating the basic layers.

At Nexperteam we have an open culture to discuss problems, trying to understand the depth of the issues and finding an effective solution. If you are looking for sound security advise or want an open and transparent check done by an independent party, feel free to contact us.