Two Factor Authentication Implemented

We are pleased to announce that we have added simple Email One Time Passcode based Two Factor Authentication for flowlog.net.

Back Story/Long Version

2nd (or Multi) Factor Authentication is important for security, as defending the user's account and the application is difficult when being completely dependent on a password. What do you do with malicious bots or visitors who try to brute force their way into users' accounts by trying to guess the user's (possibly lame, hopefully radical) password? If you lock an account after a few bad attempts, a malicious user can easily lock a legitimate user out of their account by simply guessing incorrectly until the lockout is triggered. This is just one example of how ne'r-do-wells might burden flowlog.net and it's membership if only using single factor auth. Therefore, we've wanted to implement some kind of 2FA from the beginning, but what implementation would suit our needs?

We wanted something that would be simple to use and implement, while being robust in it's security. It also had to be Free/Open Source Software. We first looked at the two big players. Google Authenticator and Authy. Google was pretty much out by default, due to the fact that it would know too much about the users' phone, data and identity. This might have been acceptable to some flowlog.net members, but we need something that can be used for all accounts and we weren't going to force a compromise of privacy on members if we could help it.

With this in mind, we took at look at Authy. After being data mined to gain access to their precious API, your author started digging into the docs. This was short lived, because you find that you would have to collect your users' phone numbers, email addresses and country codes and silently hand those over to twilio in the background... Yeah, no thanks. They claim they only "need" said data to use as a "unique identifier"(paraphrasing from memory) for the user. If it were simply a unique identifier, then they could just generate a random string instead. Why the need to use data that can be tied to your real world ID? I don't know what their rationale is, but whatever the case, it's not in line with flowlog.net privacy requirements.

After taking a break to forget that aggravating waste of time (isn't it curious how everyone wants you to use 2FA for your security, but they want you to subjugate yourself to use it?), I took another look around. I had been recently reminded of Free OTP after installing F-Droid on my phone, and took a look at that. The phone app is Free Software (graciously sponsored by Red Hat) and I found Free Software packages for Laravel, but implementation was not immediately clear to me, and I wanted something simpler to start with. So, FreeOTP would have to wait, at least. However, while looking into FreeOTP, I stumbled across some mention or examples of Email OTP (in general) and thought it would be easy to just implement that completely in-house. So that's what we decided to do.

TLDR;

Our simple, Email One Time Passcode implementation requires no new information from members. no phone app to install, no second device is required, and it is easy and quick to use. This is a mandatory part of the log in process, but hopefully doesn't represent an undue burden for people. Due to the realities of protecting user sessions and accounts, we feel it is easily justified and the least disruptive method overall. Single Factor Auth is only easier before your account is compromised or when all flowlog.net users are legitimate. It would not seem so convenient if members were locked out of their paid accounts (or worse), or having to deal with spammers (or worse) in the forum and issues tracker. We appreciate your forward thinking in this matter and we hope you agree with our choice.