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.

When the bounty was announced, 1BTC was worth less than $1000. Stake.com will not pay such a sum at the current rate, but Stunna is still active, and Powerglove may still receive something if this is successfully carried out. Great work Powerglove

If that reward is really still valid, it will be a very good thing for you! The work you have done deserves all that money.

But first you have to wait for this patch to be implemented. Then they see the search for the reward. Good luck.

When the bounty was doubled, it was worth about $1000. When the topic was created, Bitcoin was worth twice as much (and I think the bounty was 1BTC back then).
There are more forgotten topics with high Bitcoin amounts, but still, $1000 would be nice too

I just sent theymos the fifth (and hopefully final) iteration of this patch. All that changed was the addition of the "OTP" field on the guest-kick login screen.

With the iterating and testing up until this point, I reckon that I've spent ~140 hours on this (not looking for props, just sharing something that others might find interesting).

I think I've done just about everything I can to raise the probability of theymos merging this: I'm hoping it happens in the next month or two (and I estimate that that's fairly likely), but I don't really have any insight into theymos' schedule/timeline/constraints, so it may spill over into next year.

Anyway, I had to dig pretty deep to get this patch to the point it's at now, so I'm looking forward to the warm, fuzzy feeling that comes with knowing that my work has made a positive difference. (I'm also looking forward to trying my luck with the 2BTC bounty that Stunna left open.)

Your efforts and dedication to this forum motivate me to contribute more to the forum. There is no doubt adding 2FA security measures will add an extra layer of protection for the forum members and eliminate potential threats from scammers and hackers.  

Also, i love the idea of giving theymos a set of 2FA primitives which will give him more room to implement the features according to forum needs. If theymos approve the idea and implement it into the forum then i think adding a guide for users who is unfamiliar with this concept will encourage users to use these features to make their account more secure.

So, in order to gain access to the account, one must still sign a message from the submitted staked address. That makes more sense now, I missed that part. 

That would give you access to restore the account. It's kinda like someone who posts your Bitcoin address to receive a payment: it's dumb

WHAT if someone enters my staked address since it's public how will the admin verify this?

The security question is optional and not recommended - I don't see getting removed though.

I get what you're saying, but I think that there are too many other places in the patch (it's also on the login screen, on the settings page, etc.) for it to make sense to clarify its meaning everywhere it's used.

The first time it's likely to be encountered is here:



There's a tooltip on the "OTP" field that looks like this:



I don't think it's a big deal if people don't actually know what the letters stand for and only end up internalizing "OTP" as "authenticator code".

In the second-to-last patch I sent theymos, I also added a bit of text to the help page, in case people miss the tooltip.

That's a good suggestion. I think it makes a lot of sense to (partially) disable that feature. I'll ask theymos.

Yup, that's a good idea, too. I mentioned earlier in the thread that I've considered making "address staking" a proper forum feature. My plate is already pretty full though, and theymos and I are working out some stuff in the background that'll affect whether I keep working on forum improvements or not. I've got a backlog of other patches to get through (thread banners, quoting from locked threads, the [r] tag, etc.) but after that, things get hazy. I've got no interest in working on Epochtalk, so it's unclear how much value I'll be able to add long-term.

Yeah, I get that you're curious, but there are security implications to consider and some details that I don't want to get into, so you'll have to be satisfied with what I've already shared.

Wow that's an amazing addition to your profile @PowerGlove


Ok interesting... I mean I still didn't get what the flaw was :p

But yeah keeping your amazing record in mind I'm sure it was something big that deserves a badge.... and did you mange to secure any of these


Just read it... yeah it's fine if you don't want to share though.

It should be replaced: "To help retrieve your password, enter a Bitcoin address here that you'll use to sign a message.".

It looks clean, and I hope to see this patch released later this year.
While you are doing this job, is there any chance for Security question to be removed in future, if theymos approves?
I think this can create more problems, and it's way more insecure than 2FA, especially when we know many people are still using one-for-all weak password  

I had to look up the meaning: One-time passwords. You may want to clarify that.

It doesn't. Resetting your password (via e-mail) disables 2FA (or it used to, read more below).

That's what the "disable 2FA on a password reset" logic is for. The thinking there is that it's out-of-scope for the 2FA system to protect your account even in the face of your e-mail being compromised, so disabling 2FA on an e-mail based password reset is the "self-service" option to get back into your account if you've lost the ability to produce valid OTPs.

But, your post made me think about it a little more, and I reckon that giving users a checkbox to control the process is better than just unconditionally disabling 2FA whenever they reset their password, so I sent theymos an updated patch.

The password reset screen used to look like this:



Now, it looks like this:



In case you find these details interesting:

While working on the 2FA patch, I found a security flaw in SMF 1.1.19 that has to do with the account settings page. I got pretty excited at first (I've been eyeing the "glider" badge for a while), but when I tried the exploit on the live site, it failed.

Disappointed, I sent theymos a PM saying that although it didn't work maybe there was value in double-checking why it didn't work, just to make sure that the hole was plugged properly. I got his PGP key and sent an encrypted e-mail disclosing the flaw and the (non-working) exploit.

I was pretty bummed out at this point, figuring that I had missed what was probably going to be my one and only shot at earning the badge. When theymos got back to me, he shared a snippet of code with the mitigation that had defeated my exploit. It looked solid to me, so that was that.

The next day, curiosity got the best of me, so I patched my version of SMF with the mitigation theymos shared, and tried to see if I could find a way around it. I got pretty excited for a second time when I found a way to partially defeat it. I sent another disclosure e-mail, this time with a working exploit, but it was very low-impact and theymos couldn't justify giving me a badge for it.

A couple days later, I was having a restless night's sleep and couldn't get my brain to stop turning the problem over and over. Eventually, I came up with something good enough to try, so I jumped out of bed to test it. I got pretty excited for a third time, and sent another disclosure e-mail. This time, I basically knew it would all work out, so I kept a page open and kept refreshing it every hour or so, waiting for the badge to show up.

Thanks, man. I appreciate that.

Hehe, yeah, I got a reward for it (but weirdly, I think I'm more pleased about the badge).

Besides the sometimes long account recovery procedure using PGP and bitcoin addresses, how can you regain access to an account you lost your 2FA codes to?

Since there are no back up codes, and I read up here somewhere that email resets will switch off the 2FA feature, is that the only (timely) way you can recover an account with?

Why does resetting the email address turn off the 2FA code anyway? If somebody does it, they might not realize that their 2FA is now off so its better to add a message in the email or on the forum "reset password/email" screen.

Read up 3 posts

I'm more curious how serious the security flaw was, especially since he found it in the publicly known open source code.

This is some great development for the forum👏 👌 and in the coming years I foresee account hacks minimizing greatly,  possibly account sells will drop too unless 2FA isn't enabled .
Thanks @PowerGlove .

Seeing the writing relates to finding security  flaws etc...did he score himself the reward for finding any bugs too? If yes congrats to Power🥊

Sorry for the off topic, but I noticed this now and didn't want to pass up the opportunity:



Congratulations @PowerGlove for this badge, which shows what a great contribution you have made to this forum!

I can only offer a guess: I'd say there's something like a 90% chance that this'll get merged in the next 2 months. (+1 month if theymos has more notes for me.)

I'm not aware of any plans to do that, but I did structure the code in such a way that a closed beta would be possible. That is, the activation of each of the modification points depends on the value of a configuration variable. So, if there's ever a need for theymos to disable 2FA site-wide then he has a mechanism to do that. The same mechanism could be used to make the feature available to a limited set of users (i.e. instead of setting that configuration variable to true or false, it could be set to something like: isset($_COOKIE['2fa_beta']) && in_array($_COOKIE['2fa_beta'], $beta_key_list)).

Of course, to filter out undesirables, only the construction method for a working beta key should be sent to each candidate, and not the value itself; I propose: hash('sha256', $true_location_area51 . $theymos_nipple_count . $skynet_override_poem . $key_sharing_mitigation). (That is, if you don't know where the materials recovered from the Roswell crash site are actually kept, or how many nipples theymos has, or how to lull Skynet into standing down, then I don't see how your feedback could be useful. It should go without saying, but $key_sharing_mitigation is your unique MJ-12 call sign. If you're not already an MJ-12 member then get a candidate ID here, write it in thick black marker on 8x10 cardstock and proffer it to the sky on a full moon. You will be contacted.)

Cool update.
I was just mentioning you and this 2FA patch few days ago in our local board, and from what I hear people are waiting to test how everything will work.
Can you tell us any release dare and are you accepting early beta testers?

If I remember correctly few months ago suggested that you should receive special developer badge in your profile, but this is even better

I just sent theymos the third iteration of this patch. The biggest user-facing changes are:

(*) The "Confirmation OTP" now protects all of the account-related settings (previously, it only protected the 2FA setting itself).

(*) Resetting your password via e-mail will disable 2FA (if it was enabled before, then remember to go and manually re-enable it after login).

In case anyone is curious about my kewl new badge: I discovered and suggested a fix for a security flaw in SMF while working on this version of the patch.

Good to hear that, because I am not a big fan of QR codes at all.
Yes, they can be useful sometimes, but not as much like some people are trying to present, and there are some hidden dangerous with using them.
Recently I tried scanning QR code from one bike and it was impossible to do it, it gave me error all the time and I tried using many different programs.
On top of that some hardware wallets like safepal are using stupid closed source encryption with QR codes, and that is no go for me.
Let me just say that everything in China is full of QR codes, and they plan to use them with their CBDC slave wallets, that should be red flag for everyone, and I don't mean red PRC country flag.

Sometimes these things become addictive, especially when everything starts to go well and work.
A few years ago, it was also like that, but then time became shorter and expenses were increased, the person has to filter what can be done or not.  

Don't worry, the QR code is just there as a convenience, you can ignore it, if you like, and manually copy the displayed secret into whatever application you're using to generate OTPs. (You can also hover over "Shared secret (Base32)" to see a tooltip with the other details you might need while importing it.)

The approach that's likely to be taken (at least until the need for something more complicated becomes obvious) is for 2FA to be disabled on a successful password reset. So, if you can't produce an OTP anymore (lost your phone, laptop, or whatever) then going through the "Forgot your password?" process will restore your access.

Hehe, yeah. It's not exactly what I had in mind for myself when I joined Bitcointalk, but I do enjoy working on SMF, and PHP is growing on me, too.

I'm thinking along the lines of using the standard address signing or PGP signing recovery procedure if you get locked out of your account because of OTP. That's how it's done with forgotten emails and passwords. But even that could be done slightly faster if they started getting more priority from staff.


I mean, it's not every day that you stumble upon a PHP (and specifically Simple Machines Forum specialist) bitcoiner.

Well done PowerGlove!
You should receive special developer title in your profile if this gets approved.
I hope QR code will be only optional and not mandatory like on some websites, but this preview looks great.

Is there any chance of something getting messed up with code in future that could permanently disable login to bitcointalk forum?
To prevent this potential problem there must be some fallback option for that, without reducing security.
We also don't want hacker abusing this to somehow attack bitcointalk.

This implementation of 2FA/TOTP looks almost the same as other forums that I use and where I have 2FA/TOTP also enabled which is great! It basically means that users who use it wouldn't need to adapt to a new "layout" or method, they would just have to repeat the same steps that they already did in other places that they also browse. Simplicity at its best, congrats once again @PowerGlove. I assume that before this goes live (if it goes), theymos just wants to explore the ins and outs of the code to make sure there isn't anything left to be exploited by external entities (at least that would be my deepest fear).

You really are a gem to the entire forum and deserve all the flowers you get for the effort you put in. I am one of those who is indifferent to 2FA being implemented on the forum from a personal perspective, but I can see how it will be of benefit to the entire forum users and help protect people from account thefts. Even experienced users have fallen victim to it in times past, so it's not just beneficial to newbies.

It's ironic (in a good way) reading your replies talking about a potential new addition to the forum while carrying the OP badge, which is another one of your additions to the forum. It's great having a user who doesn't just talk about charge but rolls of their sleeves and effects it

Today until 10 am forum time, it is not yet implemented.
But without a doubt, the work is extraordinarily well done. It remains to be seen whether it can be integrated into the forum system.

How has @theymos not implemented this yet? 

Yep, I've considered making "address staking" a real SMF feature. It's a pretty small step from that to using your staked address for other things (like logging in). If there's enough demand for something like that, then I'll look into it more seriously.

Thanks, man. It was a lot more work than I had planned to do (especially QR codes; I remember putting a copy of ISO/IEC 18004 on one monitor, and an empty instance of Sublime Text on the other, and thinking: "This is gonna hurt, isn't it?").

I don't know when (or even if) theymos will merge this, or how much of it he might change, but I'm happy to describe the patch I sent him.

It's an implementation of RFC 6238 (aka TOTP), which (as you probably know) is a time-based extension of RFC 4226 (aka HOTP). There are some configuration knobs for theymos to adjust, if he likes, but I've left the default settings at values that are compatible with most authenticator apps (6-digit OTP, 30-second time window, SHA1 hash algorithm, and 1 window of "look-behind", though that last one doesn't affect compatibility).

I've tried to make sure that adding this to SMF won't cause new problems, or rub anyone the wrong way, so I've aimed (as best I can) to make it feel like a native feature, and one that can be easily ignored if it's of no interest to you.

To turn 2FA on, you go into your account settings and use the new section between the "Password" block and the "Secret Question" block:



To turn 2FA off, you go to the same place:



The only other thing that changes is (obviously) the login page:



(If you haven't enabled 2FA, then you just leave the "OTP" field blank.)

In all fairness was always a fan of adding a 2FA method that would require the user to sign a message from an address linked with the account.
Might be a PITA to do that if you access the forum on mobile but would still be cool and might be worth taking into account at some point
(No web3 metamask crap... but Bitcoin Core old school message signing)

Very nice of you PowerGlove to take the time to code this ! Really curious to see what you came up with and if/how soon it will be "merged to master" !

It's part of the process, which is why the code should be reviewed by more than one person.
But I'm glad to see that things are on the right track. 

One embarrassing mistake aside, it seems like theymos mostly approves of this code.

I think there's a pretty good chance that it'll get merged at some point.

I'll send him "v2" soon (with my silly mistake fixed and one or two other improvements).

It's too early to pat myself on the back for this one, but it does feel pretty cool to be so close to the finish line on something that seemed so intractable when I started it (back then, my account was ~2.5 months old, SMF was an opaque mass of gibberish to me, and the vibe I was picking up was: "Knock yourself out, friend, but it's never gonna happen!").

Edit: Revised patch sent.

Sure, I use Aegis and it's one of the best open source 2FA apps at the moment.
I know PowerGlove knows what he is doing, but I just wanted to make sure what should not be included, and I would also add notification not to use google 2fa with cloud.

Better security can be annoying sometime, but this is by design, it's not a flaw.
I don't like carrying big heavy lock with me to secure my motorcycle or bike from thief, but there is a high chance someone would stole it without any lock or with cheap lock.
You don't have to always carry smartphone, less secure way is to install 2fa app on your computer, KeePass also supports storing 2fa keys.

KeePass is reasonably secure, it can be used to save this 2fa codes, and you with extra security it's not that easy to break KeePass encryption.
It's certainly better to use this in combination with different device, but YubiKey is also not a bad idea to have (I don't know if that is compatible).
Even some hardware wallets can be used for this purpose in combination with FIDO:
https://trezor.io/learn/a/what-is-u2f

I might be missing something, but as long as this feature is optional, I seem no harm in making it available on the forum. I think that it is always great having the option to provide 2FA, even though most users won't probably use them because it may go unnoticed / they don't care enough. Still, for the % of users that do care about it, I'm sure they would be grateful to activate it.

Like similar process that we have already employed in the forum (such as signing our addresses[1]), we can also motivate users to activate the 2FA feature, if they do seem like it could be useful for them. I see room in the forum, for example, to create a (sticky?) thread with the advantages / disadvantages of the tool, explaining how to activate it, and best practices that one could employ in order to keep the code secure. At the end of the day it would be up to the user if they so decided to activate 2FA or not.

I think that if we always look things from that perspective, then we (as a community) will never develop tools / procedures to try to keep accounts secure. Mistakes happen, it's only up to us (as society) to try to devise tools that benefit people to secure their devices /accounts (in this scenario). I think what happens in some cases is that companies sell the 2FA/TOTP solutions as something for their users to activate which will increase their security without explaining what the concept is and what may happen if something happens to the codes. This points back to the previous point that I've made - I think that the best that we can do is enlighten our user base for the meaning of such feature (believe me when I tell you that not everyone knows that 2FA/TOTP is). After that, it's up for the user to take a conscious decision.

---

@PowerGlove: I like the fact that you also changed your coding methodology regarding SMF patches in the forum and the way you develop code (for SMF at least). Like you said:
I find that way of improving one's way of acting very positive (besides the obvious useful features that you've been devoting your daily life to do for us). I think this goes with the philosophy that one can never stop learning I guess. Do keep up the good work that you've been making on that end .

---

[1]https://bitcointalksearch.org/topic/how-to-sign-a-message-990345

Reading the comments so far, I see that there's a little of that 2FA "pushback" I was talking about, so let me address some concerns:

Q: Will this new system be a hassle to use?

A: No, it doesn't change anything fundamental about SMF's login code. If you enable it, then all that happens is that a small piece of additional logic is executed (to verify the entered OTP). This verification takes place in the same code path as password verification (that is, there's no extra "step" involved, you either type in an OTP, or you just ignore that field if you haven't enabled 2FA). After a successful login, it won't bug you again (and everything else, such as cookie duration, continues to work as before).

Q: Will I have to use my mobile phone?

A: No. This is just an implementation of RFC 6238 (TOTP: Time-Based One-Time Password Algorithm). Technically, it has nothing at all to do with mobile phones. You can generate the OTPs needed for login with desktop software (like KeePassXC, which I use) or even with your own script if you're industrious enough (after all, the OTP is just a function of your "shared secret" and the current Unix timestamp). Of course, a lot of people do find mobile authenticator apps to be convenient, and this system works fine with them, too.

Q: But it's stupid to put your "shared secret" on the same device that you log in from, isn't it?

A: It's not ideal, that's true, but it's also not that stupid. There are still some important advantages to be had, even if you do everything from a single device. Your account will still be protected from phishing, and (in a lot of cases) it will still be partially protected from keyloggers, clipboard sniffers, and certain other types of malware (i.e. depending on how it's stored, it can be much harder for malware to exfiltrate your shared secret than it is for it to read the clipboard, etc.)

(Thanks to the people who left kind words, I appreciate those. Thanks for the merit, I appreciate that, too.)

Express it another way, more and more people believe that 2FA is like a best solution to secure their online accounts. Like with 2FA, their online accounts will never be hacked.

Unfortunately, see how they practice with 2FA: installing 2FA on a smartphone; login their email on that phone; login their online accounts on that phone too. So is it a good practice? They store and login all things on one device, what will happen if that device is lost or remotely compromised? 2FA can not save them.

It is annoying with me too. When they log out my accounts, ask me to log in again, type 2FA again to use my account on a same device and even with same IP address. Annoying experience.

I think it's more important to teach people how to sign a bitcoin address and encourage them to stake it on the dedicated thread we have: Stake your Bitcoin address here.

The forum has millions of users. We may have over 100,000 active users but on the thread we have only 590 pages of posts. Over 50% of the posts have quote from others of the address's posts, and more than 20% posts are discussion type of posts which means from the 590 pages only 30% posts contain bitcoin addresses staked.

I hate the captcha code and adding a 2FA is another kind of layer to face hassle. We need to encourage members to use stake your bitcoin thread more.

If comparing myself with you, I will say that I am new to bitcoin, crypto, security and safety. The platforms that I have used 2FA are the exchanges that I am using, second was when I was testing Electrum 2FA wallet. I can disable the 2FA on my exchange accounts, but there would be restriction not to withdraw for certain period of time. On Electrum which is not centralized, we can easily bypass the 2FA by importing the 2FA seed phrase into Electrum wallet and bypass the TrustedCoin 2FA setup. I have seen 2FA more useful than not.

You are using your laptop for the platforms, like this forum. The 2FA is on your phone. That will makes it difficult for your account to be hacked. Although, you are use to ways of protecting your Bitcointalk account and 2FA not needed, but some people are just not like you as they are careless. It would have happened before they know how to protect their Bitcointalk account. But assuming you leave this forum for good, you have 2FA enabled and you stake your Bitcointalk address, you can still have access to your account if you prove that you are the owner of the bitcoin address through message signing, if at all you do not have your 2FA again. The forum admin will be able to disable the 2FA for you, and you  can reset it yourself if you like.

What is more bad about it is that it is not end-to-end encrypted. Despite that authenticators with online backup is bad. Another is that anyone that have access to you email has access to your 2FA.

Security risk notice: Google Authenticator's cloud sync feature
To Electrum 2FA wallet users and other bitcoin 2FA wallet users

Permission to respond on this

---

I also want the old-school one because last year I had this issue with Bittrex where I needed to login to that exchange, which it won't allow me because it is asking for 2FA in Google Authenticator that was installed on my old phone that was lost a few years ago. I don't have a choice but to submit a KYC to them, and you know the hassle of it as it takes days to get approved, and then they will be locking your account for another day because youve changed your password.

I rarely use 2FA now, but I do make my password secure, as it is a hassle, just like logging in to Google, where there are a lot of things to do and I want them done fast.

2FA Lost Device
https://ibb.co/WsRx4K2

I am of the same opinion. I'm not a big fan of 2FA.
And I say more, I find it annoying to always have to be next to my smartphone, to access a website. Maybe it's just laziness.

Either way, I recognize the effort made to try to implement this level of security, and being something optional, I think it's good for those who like to use it.

Well, seems like we both have totally different experience of 2FA, almost all 2FA that I have are optional, exchange, game account, etc, except Internet Banking, it's not optional, but I think thats necessary. I would definitely against mandatory 2FA, moreover if it required user to input their phone number or download an app, anything that labeled 'Extra' should be optional IMHO. But then again if it's optional then it's always good to have an option.

And I believe we also had very different experience and behavior of using mobile phone, I got everything in my mobile phone, 2FA, internet banking, online marketplace that have my credit card, .etc so if I lose my phone I will immediately locked it. I have back up code for my 2FA tho so it will be easy to just install 2FA in other phone recover it.

More and more of my internet accounts require 2FA nowadays, and most of them don't allow me to turn it off. It's mainly needed because of the people who don't use proper passwords, share them everywhere, and have a system filled with malware. Those same websites nowadays run a timer to kick you out after a few minutes of inactivity, which makes it even more annoying. To me, 2FA is just a hassle. I have old Gmail accounts that don't let me login with my password anymore.
This makes me truely appreciate the old fashed forums that just keep me logged in for years. A browser cookie is very convenient.

That being said: as long as it's optional, I'm not against it. But would it really help if someone gains physical access to my mobile phone? I don't want to lose the convenience of being logged in when I use it.

---

---

Google Authenticator just told me I can now backup my 2FA codes in the cloud. Lol.

Did some people actually defending the lack of extra security for their account? I mean why? if they don't want it they can just turn it off, but it always good to have an option.

I read the whole OP post, several times, but I didn't find what type of 2FA would be implemented, will it be Email based, or using 3rd party App, or mobile messaging. The least effort might be Email since we already registered our email in this forum, but wouldn't it be less effective since most of the hacked account got their email hacked too? I mean if the account is hacked and the email is not hacked, than we could just use 'Forgot Password' to recover the account,

Well done PowerGlove, we are glad that we have you.

I think the 2FA will be those of authentication apps like Aegis because it is the most secure. I like something about this forum veteran members, they know what not to go for.

If a bitcoin address is staked or has been used somewhere before on this forum, signing a message with the address will still be enough proof and the account can be recovered. It would be done in a way that it would be recovered just as it is recovered on other platforms that uses it. But to avoid the inconveniences, better not to lose the 2FA secret code.

You coded a standalone totp for your implementation of 2fa ? You really know how to go the extra mile. Curiosity level peaked!

Well done! Another ''forum main dev'' project 
I like to hear that 2FA will be a optional feature, but depending on how easy is to use I would would probably use it in bitcointalk forum.
Just make sure not to add any 2FA that is connected with SMS and phone numbers, this is literally worst thing related with 2FA.
Now that being said, people should be aware of risks when using 2FA, that means if you lose backup codes you will lose your account, and not even theymos with all his mighty powers will be able to restore it.
Speaking about theymos, I wonder what is going to be his opinion about this

@PowerGlove, it's honestly a great gift to the community if they implement your idea. 2FA has been expected by most users so far, they expected to improve account security rather than relying solely on strong passwords, signed bitcoin message, and using an active email.

I'm curious about how it works and how it integrates, but first I'd like to thank you for your hard work contributing immensely to generating important code for forum improvement.

Doing this type of coding takes a lot of effort and dedication, no doubt!
To have dedicated 90 hours to a project, which you don't even know if it will be implemented and which does not obtain a financial return, is really to be congratulated!

Regardless of the result, you deserve all the credit for those efforts!
Thank you for continuing to work to make this community even better.

That's a good news then, because in my short time on this platform i also read many threads created on this same issue (lack of 2FA), well, i hope it will release soon, as dear op you mentioned why you didn't shared the picture of new enrollment but i hope the theymos will look into it soon.

You are really doing a favor to this platform, big thanks for your great contribution.

The more security the better. BUT and this is the big important BUT.
We can't get people to stop using centralized exchanges, closed source wallets, ridiculous obviously scam platforms, and so on.
Getting people to use 2FA here as an option is going to be difficult except for some core users.

Not saying it should not be done, just that I see the fighting the battle fatigue as a reason for people not to be talking about it / supporting it.

But good job on doing it.

-Dave

Hey, everybody!

So, as some of you know, I've been working on adding (optional) 2FA to the forum for a while now. I mostly finished this work late last year, and it's just been sitting in a folder, waiting for its day in the sun.

I've finally put the finishing touches to this one, and sent it off to theymos...

Most of my patches don't end up getting merged, and some of the time that's because of the difficulty in recasting diffs made against SMF 1.1.19 into a form suitable for the forum's customized version of SMF.

This time around I thought I'd try a different approach, so I put the bulk of the code in a new file: TOTP.php, and then included a small "example integration" of how this new file might be wired up to the rest of SMF.

The idea here is that rather than making all of the design decisions myself (e.g. how the settings UI should look/work, how it should interact with password resets, etc.) I've instead focused on giving theymos a bespoke set of 2FA primitives and a working example of how to use them.

This patch took around 90 hours to design, develop and test. I generally prefer to write code from scratch when I have the time, and that preference worked out very well for this project; I was able to whittle things down to a lot less (total) code than if I had pulled in any dependencies.

I know this post could use more info (and some images), but I expect a fair amount of iteration to happen based on theymos' feedback, so I'll describe the system in more detail once things firm up. In the meantime, if anyone has any questions about the implementation (as it currently stands), then I'm more than happy to answer them.

On a more serious note, I find a lot of the dismissive attitude around 2FA to be quite confusing. When I'm digesting old topics about this issue (say, from before 2017, or so) the vibe I generally get from that group of users is that (optional) TOTP would be a really nice thing to have, full stop. But recently the sentiment seems to have switched, and instead of admitting that it would be a nice option to have, people seem very focused on picking it apart and reminding whoever posts about it that it's not a silver bullet, etc.

I'm not sure why the average opinion changed like that (maybe because 2FA on SMF became such an unlikely idea that people started "defending" the lack of it?), but I align with the more optimistic group and think that a correctly implemented TOTP option makes a ton of sense (even for SMF).

Beyond the obvious advantages for the people that enable it (like making their accounts all but impossible to "phish"), I'm hopeful that it might also help with incidents like this (which is what motivated me to roll up my sleeves in the first place).