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.
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:
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.
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 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 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.
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?
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.
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.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.
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!)