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

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