1) does turning on 2FA supersede the Security Question and disable it from being able to be deleted ?
To the first part of the question: 2FA operates independently of the secret question/answer feature (that is, the two features live side-by-side and don't interact with each other, at least not
directly; see the next bit).
To the second part of the question: Yep, kind of. When 2FA is enabled, changes to your account settings require both your password (as before) and a valid OTP. So, someone wouldn't be able to, for example, go mess with your secret question/answer, even if they found your account in an already-logged-in state
and knew your password (because they presumably wouldn't be able to produce a valid OTP and would run into the daily retry-limit).
N.B. I'm not sure how many people are aware of this, but, assuming it still works the same way it did when I last looked into it, then, the secret question/answer feature
really shouldn't be used. The modified implementation of it that this forum uses bears little resemblance (logic-wise) to the original SMF feature: it no longer operates in the way most users would expect (the slightly inaccurate/misleading cautionary text on the account-settings page doesn't help), and while it can succeed in resetting your password (but not your 2FA), in that case, it will also lock you out of the account and mark it for manual review/recovery (like I said, don't use it: it's mostly just a footgun at this point).
2) jw ..how difficult/expensive would it be to implement/allow for 2FA via hardware authenticators here be, if even possible ?
It's possible. But I'd need to hear a pretty convincing argument for it before I'd spend my (limited) time working on that...
The thing is, I have an enormous amount of energy for
certain things, and almost no energy whatsoever for other (sometimes even closely-related) things.
I've developed a pretty good sense over the years for how much of something (like TOTP, or U2F, or FIDO2, etc.) is based on good engineering and how much of it is based on profit-rationale. Things that were designed by engineering-types, without anything in mind except for the problem(s) being solved have a particular style/flavor to them that I really enjoy. Things that were designed or influenced by business-types, however, usually from a position of fear or greed, have a distinctly different style/flavor to them that I really
don't enjoy. I have about a 10% tolerance I'd say: something needs to be at least 90% engineering-led for me to care enough about it to write code...
Honestly, I didn't do any kind of deep-dive on the available options when I decided to work on 2FA for the forum, I just started with the spec (TOTP) that seemed
least likely to have been infected by business interests and went from there. It took me 20 minutes of reading (RFCs 6238 and 4226) to "see" the underlying design behind TOTP and to appreciate just how simple it is (that's normally a sign to me that what I'm looking at is/was an engineering-led initiative; business-types typically push for at least enough complexity to provide cover/justification for a revenue stream or two).
I've probably mentioned this in other posts, but it bears repeating: There's an unfortunate "word cloud" surrounding TOTP that makes it easy to misunderstand how it works, things like "Google Authenticator", and "QR code", etc. make it seem like maybe you need Google (you don't) or a phone (you don't) or a QR scanner/camera (you don't) or even an Internet connection (you don't) to use it. (For example, for my really important online accounts, I retrieve passwords and generate OTPs from an always-offline Linux laptop running an old version of KeePassXC.)
Fundamentally, TOTP is about you and the server having a so-called "shared secret" that can be used to algorithmically generate time-based OTPs. In Bitcointalk's case, that secret can be thought of as a system-generated number between 0 and 1329227995784915872903807060280344575 (inclusive). That number is presented to you in two ways on the account-settings page, as a Base32-encoded string, and as a QR code, but, at the end of the day, it's just a number. In principle, as long as you know what your number is, you can generate valid OTPs.
In fact, to drive home the point that TOTP is really simple, and has nothing (necessarily) to do with Google, phones, cameras, or the Internet, let's write a tiny, offline, standalone Python script and see if we can use that to enable 2FA on Bitcointalk and then successfully sign-in with it...
This post is already a wall, so I'll skip the step-by-step derivation and just share the script I arrived at:
#!/usr/bin/env python3
import time
import base64
import hmac
TOTP_SECRET: str = 'KBXXOZLSI5WG65TF'
TOTP_HASH_ALGORITHM: str = 'sha1'
TOTP_TIME_STEP: int = 30
TOTP_DIGIT_COUNT: int = 6
def main() -> None:
now: int = int(time.time())
secret: bytes = base64.b32decode(TOTP_SECRET)
message: bytes = (now // TOTP_TIME_STEP).to_bytes(8, 'big')
hashed: bytes = hmac.digest(secret, message, TOTP_HASH_ALGORITHM)
offset: int = hashed[-1] & 15
value: int = (hashed[offset] & 127) << 24 | hashed[offset + 1] << 16 | hashed[offset + 2] << 8 | hashed[offset + 3]
result: str = str(value % 10 ** TOTP_DIGIT_COUNT).zfill(TOTP_DIGIT_COUNT)
print(f'OTP: {result} [{TOTP_TIME_STEP - now % TOTP_TIME_STEP} second(s) left].')
if __name__ == '__main__':
main()
So, now I'll go to my account-settings page and get my shared secret:
Then, I'll paste that into the above script (by replacing the placeholder secret on line 9):
We'll need to generate a valid OTP in order to enable 2FA, so let's see if our little script actually works:
OTP: 365017 [28 second(s) left].Let's check the "Enable two-factor authentication?" box and type in the OTP we just generated:
Now let's (fairly quickly, before our OTP gets too old) type in our password and then click "Change profile":
And... 2FA is enabled:
Now, let's log out and make sure that we can log back in:
We'll need a valid OTP, so:
OTP: 820946 [23 second(s) left].Okay, let's see if that works:
Click on "Login", and... Bob's your uncle.
(To be clear, I'm not suggesting that you or anyone else use the above script, though of course you're more than welcome to, I just wanted to demonstrate that there's actually
very little to TOTP, and that, if you had to, you could get by with just a small homebrew program and nothing else. I like TOTP because it's a nice, freedom-maximizing, simple algorithm that doesn't depend on anything in particular: it doesn't need OS-level support, it doesn't need browser-level support, it doesn't need special hardware or complicated/opaque/hidden software or drivers, etc.)
I wonder if implementing recovery codes would also be feasible (...)
Hey Rick. Sorry for taking so long to get back to you. I get what you're referring to, but, I don't know... I don't think recovery codes make that much sense for this implementation (in terms of value added vs. complexity added). There's already a worked-out mechanism for recovering access to your account if you lose your 2FA app/device (just do an e-mail based password reset and check the appropriate box). I guess, if people would really rather avoid doing a password reset, then, what they could do (though I don't recommend it, not unless they really know what they're doing) is keep a copy of their Base32-encoded secret somewhere, and then, if the need arises, they could either import that into something that easily accepts Base32 secrets, like KeePassXC, or they could paste/place it into the above script and (either way) then generate the OTPs necessary to get back into their account and disable 2FA (before presumably re-enabling it with a different/fresh shared secret).
