Topic: A concise 2FA/TOTP implementation (SMF patch) (Read 1503 times)

I wonder if implementing recovery codes would also be feasible (in the long term I suppose). The way this works on other websites/forums is that they are given to you whenever you activate 2FA and in the situation where you loose access to your 2FA device you can enter the recovery codes in order to regain control of your account. I do reckon, however, that these codes do act like a pointed spear on both ends - if helps you regain access to the account but also allows a malicious entity to gain control in case your computer gets compromised... The implementation on SMF doesn't seem to be that easy as well I suppose...

In terms of the code I sent theymos, there are no direct interactions between those settings (each can be changed without affecting the other), but two indirect interactions I can think of are:

(*) When 2FA is enabled, account settings (like your e-mail address) can't be changed without a valid confirmation OTP.

(*) If your set e-mail address is bogus (or otherwise inaccessible to you), and you lose the ability to produce valid OTPs (by, for example, your not-backed-up 2FA device getting damaged/stolen/lost), then you won't be able to receive the link that you need to disable 2FA as part of the password-reset process.

I think this is a good idea, but it will add more complexity and I am not sure theymos will continue to poke around it unless this is something that urgently needs to be updated.

Let me ask you to clarify one thing if you can,
What happens with saved 2FA that is activated in profile, when someone activates email change?
Do we have to create and activate new 2FA or not?

Now you can say that the "sky is the limit". 

I think there should be very few modifications as complex as 2FA. Therefore, the next modifications will certainly be easier. We just hope this doesn't make you lose enthusiasm.

Haha, yeah. It took a long time for things to settle into their final form. There were a few false starts at the beginning, and there was a good amount of trial-and-error and refining that took place throughout. From the vantage point of now having finished it, it's kind of underwhelming to look at the code (it's much more compact than you might imagine; the bulk of the code is in a file named TOTP.php and that file is about the same size LOC-wise as just the build script from FlappyCAPTCHA™).

Yup, that's a nice idea. But, security advice can sometimes backfire, and I'd hate to accidentally encourage people to write down their shared secret, or to screen-grab their QR code, or something similarly misguided. In some ways, it's actually better that people are caught a little by surprise that the shared secret disappears from view after 2FA has been enabled (I mean, savvy users won't find that practice surprising at all, and the set of people that do find it surprising likely overlaps with the set of people that would have tried to "save" their shared secret in a security-reducing way). Also, it's not like it's hard to reset your 2FA when needed (just do an e-mail based password reset and make sure the appropriate checkbox is ticked).

---

I'm thinking of suggesting to theymos that 2FA resets should show up as their own thing (distinct from password resets) in the security log. The way I see this working is that password resets will only show up as such if the password is actually changed. If you go through the password-reset process only to reset your 2FA (that is, by "changing" your password to what it currently is, and selecting the "Disable 2FA" option), then that'll show up in the seclog as "2FA reset via email" rather than "password reset via email" (and, obviously, if you do both of those things at the same time, that is, actually change your password and disable an enabled 2FA setting, then both events will show up in the seclog). Does anyone have any thoughts on this?

---

Hehe, thanks @EFS for the double merit-bomb. (I think that's my first one.)

And thanks to everyone else that left merit and/or left kind words (both here and in the "2FA added" thread). I appreciate it. Getting 2FA added to the forum seemed like a very steep climb when I initially took it on, but now that it's done, I don't really remember the pain, and it kind of feels like "Huh, that was actually pretty easy. What's next?".

Amazing work PowerGlove! This is one of the biggest positive changes in forum I have seen in last few years.
Bitcointalk 2FA implementation looks so simple and clean, but I am sure it took you a lot of time to make everything work correctly.
One small thing I would suggest is adding recommendation to members to backup and shared secret key correctly, best with open source app like Aegis or similar.

Congratulations @PowerGlove, pretty awesome feature, now you can work on the offensive security feature of 2FA because afaik, there are ways to bypass that authentication. From what I've heard, there was this one streamer that had his Steam account with a 2FA still being accessed by a third-party and at the same time ended with all of his in-game items stolen. I don't know though if it's a concern here though, just looking out.

I have just late seen this and I would like to congrats @PowerGlove for having this kind of feature now we can sleep well with having security and preventing accounts from getting compromised. Also for the future patch hope we can have the email or SMS (optional) so we can make another layer. Well by the way thank you!

Created a thread on our local with this feature: [Security] Additional Feature 2FA Implemented.

(I've been sitting on that GIF for a while.)

Thanks, man.

Very good! Any and all tools to provide more security are always welcome, congratulations on the excellent work!

Can you use physical 2FA too?

2FA added

Congrats, PowerGlove.

(And thank you. )

Perhaps for contractual reasons, they still can't do anything.

Honestly, I think you're trying to complicate something that could be very simple. SMF has new versions and continues to be forum software, well rated and widely used. Therefore, from my web developer experience, I think it would be more practical to maintain the software and update it, rather than changing everything. Of course, doing this does not invalidate the fact that it is necessary to carry out corrections to ensure that everything works as it does now. But, it is always easier to do this in more or less the same software, than to create everything from scratch.

Either way, I believe it was with good intentions that they thought about this change. Now, personally I continue to like how the forum works and is. 

I can confirm this works with KeePassXC password manager, and few other apps I tried, but I wouldn't recommend saving 24-character secret in a plain text.

Good to hear that you are trying and not giving up
I can understand theymos partially, it is not easy to change something that you worked on for a very long time.
New forum software would mean more risk for new bugs, and than he would need to dedicate a lot more time for fixing this.

The nice thing about the type of 2FA that this patch implements (TOTP) is that it's not based on "receiving" your OTP. What happens is that you "generate" your OTP (based on a shared secret and the current Unix timestamp), and then submit that to the server. In principle, as long as you know your shared secret (which, in this implementation, is just a 24-character string, like this: N4KMBX6DP5CUE6DCQ3BPOXN6), then you can generate valid OTPs. In practice, you import your shared secret into some application that generates the OTPs for you (like one of the many authenticator apps, or password managers that support TOTP).

I've been trying to convince theymos for some time to let me take over from Slickage and get things moving again. There's a lot of cool stuff I'd like to work on, but theymos and I each have our constraints, and reaching some kind of agreement that we're both happy with is tricky.

Since you are working on this forum, I guess there is no hope to see the new forum replacing this one any time soon, or are you working on the new one as well, I remember theymos once said he needs help of coders.

I had one or two questions. How would one receive the OTP exactly? Is it via email or other 2FA apps? Normally, I don't use an email or number for my 2FA. Rather, I use Google Authenticator, or Authy, for my 2FA verification. So I was wondering, will there be support for apps like those? Previously, Google didn't support online backup of 2FA keys, but recently they upgraded it. However, I prefer Authy when it's about 2FA.

I hope this new patch gets theymos's approval.

Exactly those were my thoughts too... when I read Harizen's topic about account hack. Even I visited this thread and went to PowerGlove's profile to see if he have posted any update which I missed

I think what is stopping theymos from patching PowerGlove's this feature, is testing or lack of testing... since it's "closed source" patch and theymos himself have to verify and test before implementing.

If it was an open source patch it would have been implemented soon, because more eyes from the community to test are definitely better... and people can validate and verify faster before implementing.

P.S. I truly appreciate PowerGlove's skills so I'm not at all question his skills nor I'm saying he should share the patch. I can understand certain code can't be made public.

The very first thought that popped in my head when I heard about recent Harizen hack was "I really hope that Powerglove's 2FA gets approved by theymos soon" so its great to hear that things are moving into the right direction and that we might finally get it, hopefully in a few months.

Regarding the bounty reward, it was set in BTC and not in $$ so who knows, maybe you get that 2 BTC (I surely hope you do  ).

You deserve it, and not just because of this patch or for discovering bugs in forum.
I was secretly hoping you might take over work or help with implementing of new forum software, mostly for better mobile support, so this could be great motivation for you.
If 2FA gets introduced this year it would be one of the biggest forum upgrade in years.

Meh. I didn't do this work with payment in mind (like I said to Stunna in the PM I sent in July: I was committed to finishing this before I was even aware of the bounty). That being said, if Stunna is a hardcore sticking-to-my-word type, then I'll certainly hold out my cup.