Multi-factor Authentication

Multifactor authentication, or MFA, is an authentication method that requires at least two out of the three types of items:

• Something you know, like your password
• Something you have, like your phone with an authentication app or like a physical key such as a YubiKey
• Something you are, like your fingerprint, face, voice, or other biometric piece of information

MFA builds in another layer of protection in the authentication process by requiring more than one item in the above list. People have a tendency to reuse passwords or to use weak passwords for both personal and work accounts. It’s easy to crack into a system when someone reuses a password from an account that was breached and the password data subsequently posted or sold online. When combined with two-factor authentication (2FA), a compromised reused password is less likely to allow access to other systems.

What is 2fa?

Two factor authentication (2fa) is an authentication method utilising two of these factors. In the case of trentend this is something you know (your password) and something you have (your phone or computer).

Your password you are already familiar with, you may be less familiar with something you have using an authenticator app. We will look at that here.

Something you have

You have a phone, or a computer. How can you prove to a service that you want to access (in this case talkback), that not only is it you from your password, but also it is even more likely to be you because you have your phone?

It turns out that this is deceptively simple, and secure.

You register a piece of software, an authenticator, on your device, with the service in question. This involves sharing a secret (in the form of a qrcode, or a string of apparently random characters). The service knows the secret that it has shared with you, and can use a specific algorithm to produce time limited codes by running this secret through the algorithm. The authenticator, on your phone or computer, uses the same algorithm, and the same shared secret, to independently produce exactly the same time limited codes. The algorithm everybody knows, but without the specific secret nobody else can generate the identical codes. So when you enter the correct code, the service knows that you have the device that you registered with the service. It does this without transmitting any information anywhere (except your process for entering the code into the service). It cannot be intercepted, and if someone sees you entering a code it doesn't much matter. In 30 seconds it will no longer work to authenticate you with that service.

An Authenticator

Is a mechanism to provide a code to demonstrate the something I have without the possibility of compromising it. That is it is a no traffic code generation method. The authenticator app on your phone or computer is linked to the authentication provider (in this specific case turnstile.trentend.uk). Then on request it can be used to generate a code, know to the authentication provider. This code changes every 30 seconds, and is highly resilient to brute force cracking. This is the basis for a one time pad (OTP). The code happens one time, and for a limited time period, and is not easily guessable. Prior knowledge of previous codes does not help cracking the code. It happens only one time.

The google authenticator is perhaps the most widely known and used authenticator, and the instructions for it's use follow at the end of this article. Those instruction also serve as broadly generic instructions for other authenticators. The process is much the same whatever you choose to use.

Android authenticator

There are many authenticators available for android. I recommend aegis. You can protect your OTP's with a password (or biometric security, if your phone supports it). You can export an encrypted backup (opened with your password). I use this as my device of choice.

Linux Authenticator

Yeah, niche I know. But aegis exports an encrypted json backup, that can be imported into mauborgne. So I can capture qrcodes on my phone, and export them to my computer. Which is right handy.

Windows Authenticator

I haven't used it, right. But 2fast seems to tick a lot of boxes. It's open source, free, with a decent feature set, and the roadmap and github activity suggests it's heading the right way. So if I was using windows, I would probably try 2fast.

Google Authenticator

Is a widely known and used authenticator, available for iPhone, iPad, and Android devices. You can have it on iOS, iPadOS, and Android if you really want.

You do not need a Google Account for this. While you can obviously use it with Google's system you can still use it with other third-party services without linking your Google Account to the authenticator.

Given that the system relies on you either entering a set-up key or scanning a QR code, it is highly advised to set up the 2FA on a different device than the one you're setting up Google Authenticator on.

How to set up Google Authenticator for iPhone and iPad

1. Download Google Authenticator from the App Store to your device. It is free to download.
2. Sign into whatever service you want to enable 2FA for, and attempt to set it up. This could be an option in account settings under a section marked "security" and an option offering to "set up two-factor authentication," for example, but this will vary between services.
3. When asked, you should select to use an authenticator app. You may be recommended to use specific authenticator app, so check that Google Authenticator is on that list.
4. Once presented with either a QR code or an authenticator key, open Google Authenticator on your iPhone or iPad.
5. If this is your first addition to the app, you will be asked how you want to add the code directly. Otherwise, select the plus symbol in the bottom-right of the screen.
6. If a QR code is presented to you in the site or app you're setting up 2FA for, select Scan a QR Code, then use your device's camera to scan the code.
7. If a key is offered, enter in the account name (usually the relevant email address) and the key provided to you on-screen. Make sure to select whether it is Time-based or Counter-based if the account system advises as such, otherwise leave it to Time-based.
8. You will then be asked to confirm that the authentication system has worked. Enter the six-digit code appearing on your device's screen into the app or service you're setting 2FA with as confirmation.

Once you're set up, you will be asked to use the authenticator app to generate a code to log into services, whenever you log in.

This is straightforward, as all you need to do is open Google Authenticator, look for the service and account name relating to it, and then read the associated six-digit code. Since the code changes periodically, you may want to wait until the timer expires and a new code appears, to maximize your code entry time.

You can enter the security details manually, but a QR code is quicker.

If you're entering the code into an app on the same device, tap the code to copy it to the clipboard, which you can then paste into the app's textbox for entry.

How to delete account listings from Google Authenticator for iOS

1. Open the app and tap the three dots in the top right.
2. Tap Edit.
3. Tap the pencil icon next to the relevant account.
4. Tap the trashcan.
5. On the confirmation box, tap Remove account.

Remember that removing an account from the Google Authenticator app doesn't affect the status of 2FA on the account itself. If you wish to remove 2FA from the account, do so before removing the Google Authenticator listing.

Any old iron

There are many different authenticators than are mentioned here. You may need to exercise your judgement and research alternatives if you wish to use one. There are reports of rogue applications that have been found to expose secrets. The authenticators that are mentioned here fall into two categories:
1. Open source, where the application can be shown to have been built from the open source code, and the open source code provides no known mechanism to expose your secret.
2. Google authenticator, which can be subject to no such scrutiny, but is relatively ubiquitous, and those appley chappies need something that 'just works'.

I will offer, as part of the suite of services on trentend, a bitwarden (technically vaultwarden) instance. Where people can store both passwords and TOTP (time-based one time passwords).

Walk before you can run though.

...it will if you put in the correct password and code. Did you remember that your username is all lower case russ?

(i've just been running updates, and rebooting, so you might have caught it at the wrong time)

I've checked it here, and all is working. It has to be an error in your username, password, or one time code.

What are you seeing? If it logs you in and gets to asking for the code... then it's an authenticator problem

Are you taking too long to enter it, and it timing out?

Are you using the same authenticator? Are you sure it was generated from the same qrcode or secret if it's a different one?

It's a fair opinion, at face value. Although I would argue that it misunderstands the modern internet. Perhaps I should explain why.

Why 2fa?

Simply because it massively increases the security of the login. I cannot control {easily, reasonably, without massive admin overhead} the passwords users choose. Ethically, and from a security perspective (if I know, a breach of that knowledge by me becomes a significant vulnerability) it's better if I don't. It's your business, not mine. If I have zero knowledge, the passwords are salted and hashed, and I cannot register a something you have against your username (because you control access to that through your registered email address), then your login is demonstrably yours to lose. Which is better.

On the other hand, if you have a security breach that potentially exposes your password (like, for example, if you re-use it elsewhere and that site has a security breach, or you use lastpass to manage your passwords) then your actions expose my stack, and make my life harder. Which I am not a fan of. Better a little bit of extra work spread amongst everyone, than me having to pick up the slack.

This allows things to be more self-managing, while retaining a higher level of security integrity to my stuff. Which I am in favour of.

In the even of a distributed brute force hacking attack, a massive range of ip addresses might be used to hammer login with username/password combinations to find a match. Because the same ip address is not used close together repeatedly it becomes hard to curtail with a fail2ban type strategy, wheres as something like crowdsec has hidden lists lacking transparency, and risks banning ip address ranges without admin level knowledge. Adding 2fa with a OTP massively slows down brute force hacking and makes it less effective.

So how does this improve things?

The best tool for the job.

There isn't any forum software with a security framework that I find entirely satisfactory. Even if there was, that means maintaining and using that forum software to maintain users and (potentially) access to other services, and other {yet to be imagined} fine grained access control.

I am a fan of using a small, well focussed, best tool for a specific job. Which is the *nix philosophy. If security and authentication is handled by forum software, then this is a larger general code base, that needs to be maintained and developed. Development and vulnerability identification and fixes is a bigger job, that happens slower and generally with added complexity. Other non-security related developments might introduce vulnerabilities. It becomes extremely onerous to scrutinise and audit the code, with a narrow selection of interested parties with eyes on it.

A widely used specialist authentication tool has a large number of eyes on it, is subject to rapid development, and regular maintenance. It can be maintained and secured on a cycle significantly more rapid than that of a large general purpose code base. It has specialist application of best practice, and is highly configurable and flexible, in ways that non-security specialist applications authors cannot hope to match.

Moving load away from the application

If an application has a login portal that is going to be subject to bot attack, and attempts at brute force hacking and DDoS (distributed denial of service) attacks. It just is. That's the modern web. An entirely different environment from that which existed when we started.

If the application has no way of logging in to it, it's much harder to compromise it's security, and much harder to subject it to a load that cripples it. Okay, it can be crawlered/botted to death...but in extremis an external authentication portal can put the whole thing behind a wall, allowing only members to go about their business unhindered. It hopefully wont come to that...but you could see an internet where it did - and application level security just wont hack it here.

A specialist authentication portal will typically have security and anti-hacking measures that an independent general purpose application just can't match.

Independence is flexibility

A specialist tool can be maintained easier more regularly, and independently of the applications that it protects. It invokes better practice, can be used to provide access to many diverse applications (like, for example, talkback but also partridge - which is something that I will be wanting to protect from scrutiny in the short/mid-term).

If it doesn't do these things, it can be replaced with something that does - totally independently of the applications behind it.

Fine grained control

On a 'devil in the detail' level. Applications do not generally have a overall security profile that is entirely acceptable.

For example 'new talkback':
Talkback is 'exposed' to the internet.

• We want people to be able to view material without hindrance.
• We don't want brute force hacking attempts to cripple performance
• We want members to be able to log in

Talkback admin panel is not exposed to the internet

• Only authorised admin users can view the admin portal to avoid brute forcing
• Only authorised admin users can log into the panel
• The admin portal has secure multi-factor authentication

The authentication itself is subject to best practice security measures

Those objectives, specifically in this case, can only be (reasonably) achieved with independent authentication using at least 2fa.

Summary

Unless taking a 'shitting your pants' now approach. A modern web framework needs to be capable of a level of security, and protecting logins with multi-factor authentication.