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

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.)