January 2021 - Web Development

What is 2 Factor Authentication (2FA) ?

Its become increasingly popular for websites these days to request two factor authentication to be added to your login for extra security. This is a good thing… but why? And what is 2FA?

There are lots of different ways to authenticate yourself. These get lumped into 3 main groups, called factors:

Something you know ( ie a password or phrase you can remember )
Something you have ( ie a device that you have with you that can give a code to assist with authentication, or something like a credit card )
Something you are ( ie a fingerprint or facial recognition, or an iris scan like in the movies )

Soo – knowing there are 3 possible factors that can be used in authentication, 2 factor authentication is simply authentication that uses a method from 2 of the main authentication type groups. Generally the ‘something you are’ type verification is tricky to implement – some cell phones and laptops have fingerprint verification, some mobile phones boast facial recognition as well… but in practice this is fairly hit and miss… you burn or cut your finger and you are locked out, or you wake up in the morning looking a bit rough, ad you are locked out.

Typically 2 factor authentication in the real world is done using a password or pin number (something you know) and something you have (either a mobile phone with an app on it or something like a credit card). Your EFTPOS card has had 2FA since waaaay back. The internet is just catching up. Its coming from a place where all you had to know was a password – a password for your email, a password for your banking, a password for your computer login… and they all must be unique and 8+ characters long with a capital and a number and a symbol and your first pets name and… well the list goes on. All things from the ‘stuff you know’ pile.

So to bring in the ‘Something you have’ group, what most places do now is they rely on your smartphone to be able to provide the ‘something you have’ component – most people live with them on their hip, and they are easy to code for. Either send them a text message (sms), or write a mobile phone app that can provide a code that only the web server and the mobile phone app can validate its a particular user.

Why is this so much better than single factor authentication?
It is becoming increasingly easy to brute force decrypt a password. Heck – some poorly written websites have even been known to store passwords in plain text, so they are humanly readable if you get access to the storage that holds them. By adding 2FA, even if someone did manage to work out the password, they won’t have access to the device that completes the authentication, so whatever it is you are protecting with authentication, is still safe as long as it requires both password and a second factor.

If you’ve got a website that you need to secure, we strongly recommend 2FA if possible. I know some people who can help make this happen

So… Its turning to crap huh?

Likely you don’t have time to read this then… but in case this is pre-emptive and not reactionary – heres some tips for when you inevitably find yourself at the wrong end of the shovel trying to work your way back to breathing space…

Firstly: Stay calm!
Your a web developer. Yeah people get frustrated, and there’ll be a bit of puffery, but think through what is the worst that could happen. 99% of the time it’ll just be some sites are unavailable for a bit, there may be some reputation damage, or if theres been a mistake with some calculations – there may be some financial repercussions. This is not ideal at all – totally, but getting stuck on this will not help get the problem solved.

Secondly: Start from the top.
In my spare time I enjoy being an audio tech around the place. Troubleshooting is very similar in that world – a mic or speaker or something isn’t working, you work out how to fix it. And the process is the same. Start at the top of the signal chain (ie from the microphone), and check you have signal at each point in the chain from there right on through to the speakers. In development land, The input into the system is the end user – what does their browser hit first. Throw in some logging at that point and make sure the browser gets there. For many PHP frameworks that means starting at the index.php file and then following through a series of includes narrowing down till you find the culprit code / system / resource failure. Don’t be afraid to throw exit statements around – the system is already broken right? If you can be doing this in a development environment – ideal – else do what you can.

Thirdly: Bring your toolbox.
A tradesperson is no good without their tools. Ours is a bit more virtual than most, but the theory is the same. Know how to get log information, get familiar with linux tools like:
grep -rnw ./ -e "text to find" //recursively find text tail -n50 filename //show last 50 lines of a file tail -n1000 filename | grep "text to find" //find text in the last 1000 lines of a file

For php – learn how to turn debugging on:
ini_set('display_errors',1); error_reporting(E_ALL);
for production environments investigate silently logging to a file – many frameworks support this, so it has minimal client impact. Otherwise send error information via email when it happens, or use services like rollbar or sentry to track issues.
Don’t be afraid to echo and exit. dump what data you do have to the browser so you know your script is on the right track. break your code down into components in order to rule out chunks of code from being the issue. Once you know what isn’t broken, you can quickly hone in on what is.

Lastly: Communicate.
Tell people what is going on. Often talking through a problem is a key to solving it – whether the person understands what you are on about or not. Just by replaying it in your head trying to package the problem for others to understand, you will think through potential areas you have missed checking. Have great communication with the key stakeholders. If people understand what is going on and what you are doing to try to fix the problems, they are likely to be more lenient, but also they are likely to feel part of the team and with a bit of control, rather than on the outside questioning what on earth is going on. Open and honest is the best policy. Don’t hide things. If you’ve cocked up – own it. If a member of your team has dropped the ball – don’t throw them under the bus, but the whole team wears the responsibility of getting things solved and communicating to the client / stakeholders what is going on.

We’re all human. Crap happens. Its how you approach it that makes the difference.