1. 119

On the settings screen is a new option to enroll in 2FA, using TOTP.

I went with TOTP because it’s easy to setup and doesn’t rely on any 3rd-party services, and works with a variety of mobile applications like Authenticator, Google Authenticator, etc.

(In case anyone is wondering, Lobsters has never used Cloudflare, so don’t interpret this as any kind of breach.)

    1. 36

      I’m a little disappointed there isn’t an option to have @jcs call and ask if I’m trying to login…

      1. 9

        …and just see how I’m going.

        1. 6

          “superblock conversation therapy” needs to be a thing.

    2. 32

      Too bad I interpret all breach denials as tacit admissions of a coverup.

      1. [Comment removed by author]

        1. 13

          Yeah, sounds like something his sockpuppet would say. :P

          1. [Comment removed by author]

            1. 11

              flyingfisch was joking

              1. 2

                Yeah it was a joke, sorry if I offended you @crocket, I didn’t mean to. ;)

        2. 4

          mine, too! he is a very very good programmer. probably the best. I hear he’s also an incredibly talented lover, but can only provide second hand accounts.

          1. 4

            I heard he makes love with O(log n) efficiency

    3. 15

      My precious karma is safe.

    4. 6

      Neat. I didn’t think that Lobsters was at risk for account hijacking. I would’ve thought that a strong enough password would be enough. Is it your feeling @jcs that 2FA is becoming the norm for webapps, to be a normal expected thing? I’ve always thought it only necessary on higher-risk services.

      Perhaps I should be rethinking both of those assumptions - is Lobsters popular enough to be targeted? Should I use 2FA everywhere, not just what I think is high risk?

      1. 9

        You addressed your question to @jcs, but it’s certainly my feeling that it’s nice to have a norm of 2FA everywhere.

        A lot of financial institutions still don’t offer it, or offer it only with significant limitations - for example, only via SMS, or without support for app-specific passwords for services such as Mint and Quicken. Of course it’s usually possible to choose ones which do, but it’s often necessary to compromise on it for other reasons…

        The stragglers are going to hold out as long as they can until there’s resounding public outcry. If we can create a culture where of course every site has a robust 2FA implementation, they’ll face a lot more questions.

        Besides, personally, my social media profiles are important to me. I could create new ones if they were compromised, but I’d lose my username and history, and my followers on sites where that’s relevant. And there’d be the stress of having to spend a couple days dealing with it - making sure nobody was using it to do a “grandmother scam” on people I know, and that sort of thing.

        1. 4

          Nothing beats the utter batshit insanity of the 2FA (or is it 3FA?) system used by my bank.

          You get a physical device that accepts an ATM card (but only an ATM card, it doesn’t work with Visa/Mastercard so I have to always have with me that stupid ATM card).

          You enter a password, some epilepsy-inducing gif (yes, gif) appears on the screen. I am not joking when I say it’s epilepsy-inducing, it flickers like hell.

          Next, you plug your ATM card into the device, and enter some PIN on the device. Then, with the card still in the device, you physically put the device on your computer screen. There are some diodes or something on the back of the device, that read the data contained in the gif optically in order to implement a challenge-response protocol.

          It’s no mystery that this works very, very poorly, as the gif is rendered in different sizes on different computers, and while you can resize the gif, it’s very hard to get the size right. It’s very difficult to get this working on a smartphone.

          After the device has read the data from your screen, it prints out a TAN which you then type in your browser. If the device has read the optical data wrong, it still generates a TAN, but one that won’t work. Once you enter a wrong TAN three times, you’re fucked, your account is locked and you have to come to the bank in person to unlock it.

          Even the bank employees think this system is bullshit and they recommend the alternative which is SMS. Ignoring the dubious security of SMS-based 2FA, I simply can’t use it as I travel internationally a lot, and I never get the damn SMS.

          1. 3

            I have started using optical ChipTAN a while ago and what you’re describing sounds quite similar. While the gif is a hack and I still feel stupid holding the reader to my screen, it is my favorite system for authenticating bank transfers so far.

            I like that it is completely independent of the computer’s software stack and requires no additional software or configuration. I only had to configure the size once per screen and it has worked flawlessly ever since. This also has the advantage that there is no two-way communication and not a lot of trusted code, no USB stack etc. on the device. (Which doesn’t mean I’m confident there are no critical bugs in the reading of the flicker code.)

            Also, ChipTAN devices should display and make you confirm at least the receiver IBAN and amount of the transaction before generating the TAN, which should help with corrupted readings. The idea is that you can compare the information to a source which is not controlled by the device generating the transaction, but obviously that’s not always possible, e.g. when the recipient is a contact I have stored in my bank’s web interface.

          2. 1

            That is impressively terrible. UK banks seem to have mostly settled on ATM card readers that you type the challenge into & get a response to type back into the web browser. Doesn’t protect you against a full MITM attack of course, but it”s a lot better than some of the alternatives I’ve seen.

            1. 1

              Ah, yeah, since the optical readout doesn’t work very well you have the option of typing the challenge manually. The problem is that the challenge is 60 hex chars long, and the device only has a 10-digit keyboard… At least Nokia 3310 had T9! (not that it would have helped with random strings…)

              1. 1

                UK banks appear to believe that an 8 digit challenge & 8 digit response are sufficient to prove ownership of the physical 2nd factor authenticator. (The chip in the ATM card). 60 hex chars is massively overkill by comparison!

    5. 4

      Does it work with any free application? For example, one that runs on OpenBSD without compatibility layers?

      1. 7

        I’m using this http://www.nongnu.org/oath-toolkit/ especially for testing. The UI here at lobste.rs does not expose the secret directly, but you can view source and get it there:

        <a href="otpauth://totp/Lobsters:XXX@YYY.net?secret=abcdefgh&issuer=Lobsters">

        Then using oathtool:

        $ oathtool --totp -b abcdefgh
        1. 1

          Thanks! That’ll work for me.

    6. 3

      In case it helps, a standard recipe for TOTP I use is to store these lines in files which are PGP-encrypted inside a git repo; the whitespace at start-of-line is significant because my shell is configured to not add to history any lines which start with whitespace. fkooman already pointed to oath-toolkit.

      oathtool -b --totp "${TOTP2FA}" | pbcopy
      qrencode -o foo.png "otpauth://totp/${ISSUER:?}:${TOTPUSER:?}?secret=${TOTP2FA:?}&issuer=${ISSUER:?}"
      open foo.png && sleep 5 && rm -v foo.png

      Replace open with xdg-open or whatever for your platform, similarly for pbcopy.

    7. 3

      Let me preface this with saying thank you and I am not ungrateful I just want to spur some conversation.

      How complicated is U2F to implement, would it work for Lobsters, and is there a reason it wasn’t done this time around?

      If it hasn’t been done because it wasn’t thought of or there wasn’t time, then it’s a great opportunity for someone to send a PR :)

      1. 2

        There’s a couple of different U2F gems, and none of them look hard to use, but to test it you’d need a U2F token or token simulator. If there’s a good way to test U2F support without messing around with Yubikeys, I’d love pointers.

        1. 3

          I don’t know about “good”, but Google has implemented a software U2F token in Java. Firefox also has the security.webauth.u2f_enable_softtoken pref, which will let you test use of U2F on the web without a hardware device. You can see the implementation here.

          1. 1

            Thanks! This is relevant to my current interests. :)

    8. 2

      what? no u2f?

    9. 2

      Great news ! One small note:

      When enabling 2FA, you are asked for your current password. However on the main setting screen, you can change your password without providing the current one.

      1. 1

        Good catch, I’ll file a bug to make password changes require the current password as well.

    10. 2

      Neat, thanks. I don’t think I’m relevant enough to be hijacked, but I turned it on anyway.

    11. [Comment removed by author]

      1. 4

        The QR code shown during enrollment contains a link with the TOTP secret, which is what you would use to add it to any other TOTP app at any time in the future. If you’re storing backup codes somewhere in a password manager or offline, just store that TOTP secret instead and you’ll be able to get back in later even if your 2FA app/device goes belly up. It’s a 16-character ASCII string, so it will be easy to store.

        1. 7

          Just FWIW: the advantage to one-time-use backup codes is that they expire after use, so you can track their use. Conceptually, TOTP codes are meant to simulate a binding between hardware and a service. You’re meant to minimize the window of time in which more than one device could have access to a TOTP secret.

          Whatever you’re doing here is I’m sure totally appropriate to Lobsters and also I’m sure you already know this stuff, but if anyone else is designing 2FA logins for some different site, food for thought.

        2. [Comment removed by author]

      2. 2

        I’m not entirely clear what you’re asking.

        The lesson I take from stories like the one you linked is that email accounts have to be extremely secure, because access to them grants access to everything else. If an attacker has compromised my email account, they can and will change credentials everywhere else to lock me out.

        I think you might be proposing a solution where, in case your email is compromised, you might still salvage other accounts because of backup codes. I don’t think this is viable if those accounts have any value; a motivated attacker will regenerate the backup codes and invalidate your old ones. Also, you shouldn’t be using a setup where the backup code alone lets you log in - it should always be a one-time code and a memorized password. Your description was vague, so perhaps this doesn’t speak to quite what you were trying to suggest?

        It’s absolutely appropriate to treat email more carefully than all other accounts, as you do. Personally I use my main email for that; that way, its password is one I actually use frequently, so there’s less chance I’ll forget it.

        Other than Google, the only service I use that has meaningful protections against that is Blizzard’s battle.net, which applies existing notification settings any time credentials are changed, even though they are being changed by a user who is nominally the correct one. (Some financial services I use also have that feature; I just don’t feel their other protections are sufficiently in-depth that the notifications will help.)

        As an early adopter of password managers and 2FA, I’ve been locked out of quite a few accounts over the years. Some I got back; some I did not. In several cases, the backup codes were the only way I was able to get back in. So yes, backup codes provide a tangible protection. They do compromise security, intentionally, but I think they are a reasonable compromise.

        1. [Comment removed by author]

          1. 1

            Ah, that’s clearer, thanks

    12. 1

      Very cool! Nicely done!