this post was submitted on 20 Jun 2023
197 points (100.0% liked)
Fediverse
83 readers
3 users here now
This magazine is dedicated to discussions on the federated social networking ecosystem, which includes decentralized and open-source social media platforms. Whether you are a user, developer, or simply interested in the concept of decentralized social media, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as the benefits and challenges of decentralized social media, new and existing federated platforms, and more. From the latest developments and trends to ethical considerations and the future of federated social media, this category covers a wide range of topics related to the Fediverse.
founded 2 years ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
From what I understand of federated authentication, your instance needs to be up to authenticate against. This doesn't help if your instance goes down. Did you have some other mechanism in mind?
That's correct. The solution would be either:
#1 would absolutely be the most preferable. There are two possible snags with option #1: sdfsdf
Cost wouldn't really be a factor for this solution and could easily be sustained from donations, you're not going to be getting a huge amount of traffic from authentication requests.
I included option #2 for the sake of completeness. This would work, but it isn't the best idea from a security standpoint. The risk can be greatly mitigated with good password requirements and the use of a strong password hashing algorithm like Argon2/bcrypt/PBKDF2/etc in combination with salting the hash. A quick look at Lemmy's code shows that they're already hashing passwords with bcrypt, so that requirement is met, but it doesn't look like they're explicitly salting it. That doesn't really matter too much in this scenario with that algorithm though, since it's going to be salted automatically anyway. Lemmy's code also shows that it's using bcrypt's default cost value (10 rounds), so it would take thousands (to millions) of years to crack the hash if you have even the most basic password requirements in place. If you add the option to put MFA in front of that, you've almost removed the risk entirely, as it won't matter in the very unlikely event that the password actually is cracked, because it's useless without access to the second authentication factor.
So yeah, there are a couple of ways to do it, and each have their downsides/tradeoffs, but the level of difficulty/effort to do it is not very high in either case.