53 votes

A bunch of updates and fixes from open-source contributors

Over the last week, a number of updates have been made by people other than me contributing code to Tildes through its open-source repository. I wanted to make a post to highlight some of these changes and let everyone know about them, since there are some great updates and fixes in here:

@deing made it possible to create links that will pre-fill the subject and message for private messages. For example: https://tildes.net/user/Deimos/new_message?subject=Test+Message&message=Please+don't+actually+send+this+to+me

@blitz saw me make an offhand comment about a rare bug when someone submits a link to an IP address, and got a development environment set up and fixed it right away.

@Bauke has been on a tear, fixing a lot of long-outstanding issues and adding features. So far:

  • Added a way for users to view their two-factor authentication backup codes (previously you could only see them at the time you activated 2FA).
  • Added "View Markdown" for comments and text topics. This is inside a new "More" dropdown menu, and will show you the markdown that the poster used, so that you can check how they did some formatting or copy-paste if you want to use someone else's post as a template of sorts.
  • Added new settings (under "Site behavior settings" on the Settings page) to always open links to Tildes groups and users in new tabs.
  • Fixed a few issues with inconsistent interface elements and styling.

There are multiple more merge requests still waiting for me to review, and I'll probably be making some other posts soon once some of those get merged in as well. Thanks, the contributions are greatly appreciated! If anyone else is interested in looking into contributing, the CONTRIBUTING file in the repo is probably the best place to start.

And as usual, I've topped everyone back up to 10 invites, accessible on the invite page.

8 comments

  1. [5]
    blitz
    Link
    I had no idea Tildes had 2-FA! I'm gonna turn it on right away. I'm against this specific feature, though. Showing your 2FA backup codes only once is a security feature. If you lose them, you...

    Added a way for users to view their two-factor authentication backup codes (previously you could only see them at the time you activated 2FA).

    I had no idea Tildes had 2-FA! I'm gonna turn it on right away.

    I'm against this specific feature, though. Showing your 2FA backup codes only once is a security feature. If you lose them, you should be required to generate new ones, and Tildes should send you a notification (via message or email, though I see tildes doesn't actually store your email address).

    NIST Special Publication 800-63B is my bible when it comes to making decisions about passwords, and as for everything it has opinions on, it has very specific things to say about Look-Up Secret Validators:

    5.1.2.2 Look-Up Secret Verifiers

    Verifiers of look-up secrets SHALL prompt the claimant for the next secret from their authenticator or for a specific (e.g., numbered) secret. A given secret from an authenticator SHALL be used successfully only once. If the look-up secret is derived from a grid card, each cell of the grid SHALL be used only once.

    Verifiers SHALL store look-up secrets in a form that is resistant to offline attacks. Look-up secrets having at least 112 bits of entropy SHALL be hashed with an approved one-way function as described in Section 5.1.1.2. Look-up secrets with fewer than 112 bits of entropy SHALL be salted and hashed using a suitable one-way key derivation function, also described in Section 5.1.1.2. The salt value SHALL be at least 32 in bits in length and arbitrarily chosen so as to minimize salt value collisions among stored hashes. Both the salt value and the resulting hash SHALL be stored for each look-up secret.

    For look-up secrets that have less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

    The verifier SHALL use approved encryption and an authenticated protected channel when requesting look-up secrets in order to provide resistance to eavesdropping and MitM attacks.

    13 votes
    1. [4]
      Deimos
      (edited )
      Link Parent
      I've been thinking about this since you posted it, and I really can't figure out what it would be intended to protect against. Here's how I'm thinking, let me know if there's somewhere that I'm...

      I've been thinking about this since you posted it, and I really can't figure out what it would be intended to protect against. Here's how I'm thinking, let me know if there's somewhere that I'm going wrong:

      Viewing the backup codes requires the user to enter a 2FA code (or one of the backup codes themselves), so anyone that's able to do it already has the ability to pass 2FA validation for that user. If they had one backup code, this could allow them to get more of them (up to 9), but just having more backup codes seems like an extremely niche threat, since they could have used it to completely disable 2FA instead.

      Hashing the backup codes in the database seems reasonable anyway, but that would be intended to protect the codes in a case like a database breach. If they're hashed, even if someone gets the user data, they wouldn't be able to see the actual backup codes (just like with passwords). However, the user's TOTP secret itself is also stored there, and isn't—and can't be—hashed, so a database leak already means 2FA could be compromised.

      Plus, if we get to the point of a database breach, the game's already over anyway. All of the data is in the database, so there isn't really anything else for them to use credentials to get access to. Like, if the end goal was logging into an account to get access to that user's messages, those are also in the database already. Depending on the account, logging into it could let them do some damage/vandalism on the site, but that's generally reversible and a pretty minor problem overall if the database was breached.

      So I don't know. It seems like reasonable advice in theory, but I just can't come up with any case where it would make any kind of difference in practice. It would only seem to matter if there was some way that the backup code data could be accessed without the actual TOTP secret being accessible too.

      4 votes
      1. blitz
        Link Parent
        Very good points! In practice this document is written for government agencies with much more complicated access structures. Maybe it's unnecessary for something like Tildes. Still: Tildes is...

        Very good points! In practice this document is written for government agencies with much more complicated access structures. Maybe it's unnecessary for something like Tildes. Still:

        Viewing the backup codes requires the user to enter a 2FA code (or one of the backup codes themselves), so anyone that's able to do it already has the ability to pass 2FA validation for that user. If they had one backup code, this could allow them to get more of them (up to 9), but just having more backup codes seems like an extremely niche threat, since they could have used it to completely disable 2FA instead.

        Tildes is unique among the sites I use in requiring a 2FA code to modify 2FA. I'm not sure how I feel about this either, since my thinking is that the authenticated device itself counts as a second factor, so requiring only the password to access 2FA settings is reasonable to me, and is actually a benefit in the case that I lose my other factors but am still in possession of an authenticated device.

        Hashing the backup codes in the database seems reasonable anyway, but that would be intended to protect the codes in a case like a database breach. If they're hashed, even if someone gets the user data, they wouldn't be able to see the actual backup codes (just like with passwords). However, the user's TOTP secret itself is also stored there, and isn't—and can't be—hashed, so a database leak already means 2FA could be compromised.

        Hashing the backup codes implicitly foils side channel attacks like non-constant-time compares. It also means that the backup codes can't be leaked in some other partial database compromise.

        2 votes
      2. [2]
        pseudolobster
        Link Parent
        I've never actually used it, but can you "stay signed in" if you have 2FA enabled here? It seems like an edge case, but I suppose if someone compromised / got ahold of my laptop, and I've got my...

        I've never actually used it, but can you "stay signed in" if you have 2FA enabled here? It seems like an edge case, but I suppose if someone compromised / got ahold of my laptop, and I've got my password saved in my browser's autofill, with no master password set, along with an active session cookie, someone could use the session cookie to get another 2FA code, then they've got both my password and an active 2FA key.

        It's unlikely, and it'd require a sort of perfect storm of ineptitude on my part, but is that theoretically possible?

        1 vote
        1. Deimos
          Link Parent
          If I'm understanding you correctly, it shouldn't be possible. Like @blitz said, Tildes is a little unusual in that it requires you to supply a 2FA code to be able to view backup codes or disable...

          If I'm understanding you correctly, it shouldn't be possible. Like @blitz said, Tildes is a little unusual in that it requires you to supply a 2FA code to be able to view backup codes or disable 2FA.

          The positive side to doing that check is that it prevents someone with access to a logged-in device or cookie from being able to use that to circumvent 2FA, but... they're already logged in to the account, so being able to log in again isn't very meaningful. Hypothetically there's a situation where you step away from your laptop for a minute and without this protection, someone would be able to leverage that momentary access into being able to log into your account later on a different device without getting blocked by 2FA. That's starting to get into pretty elaborate attacks to be worried about for an account on a message board though.

          If we didn't ask for a 2FA code, it opens up some (pretty unrealistic) attacks like that, but the benefit would be that people who lose access to their 2FA device (e.g. by having their phone die or losing it) would be able to disable 2FA so they're not locked out of their account. Being able to deal with that situation is also one of the main purposes of the backup codes though.

          1 vote
  2. blitz
    Link
    I think my ability to set up a dev environment and get immediately to fixing the bug is much more a testament to the level of documentation and automation surrounding setting up the dev...

    I think my ability to set up a dev environment and get immediately to fixing the bug is much more a testament to the level of documentation and automation surrounding setting up the dev environment.

    The only change I had to make was to find an Ubuntu box that used libvirt instead of virtualbox (since libvirt is waayyy faster and I don't have virtualbox installed). I ended up using nrclark/xenial64-minimal-libvirt.

    10 votes
  3. unknown user
    Link
    Excellent work. Love the addition of the Markdown preview. I was also going to say something about the positioning of the "More..." menu, but it's been moved behind the "Reply" button recently,...

    Excellent work. Love the addition of the Markdown preview.

    I was also going to say something about the positioning of the "More..." menu, but it's been moved behind the "Reply" button recently, just like I was intended to suggest.

    The addition of pre-composed PMs is nice, too. Could allow for some manual show-of-hands for a private/semi-private event.

    5 votes
  4. Kuromantis
    Link
    Should have used something like /user/[blank] and subject=example and message=sample+text. On a more serious note I was thinking of asking whether the view markdown feature was FOSS at work and I...

    message=Please+don't+actually+send+this+to+me

    Should have used something like /user/[blank] and subject=example and message=sample+text.

    On a more serious note I was thinking of asking whether the view markdown feature was FOSS at work and I thank the people /suspended thanked on his comment too. (Thanks!)

    3 votes