this post was submitted on 12 Dec 2021
32 points (100.0% liked)

Lemmy

12524 readers
10 users here now

Everything about Lemmy; bugs, gripes, praises, and advocacy.

For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.

founded 4 years ago
MODERATORS
 

While @nutomic@lemmy.ml and I do have a lot of issues that are going to take us a lot of time this upcoming year, its still useful for us to hear what your most desired features for Lemmy are, and prioritize them.

If they're smaller, we could get to them fairly quickly, or others wanting to contribute could see whats most wanted.

Outside of just posting them here, make sure github issues exist for them (this is what we work from), and do a thumbs up react for all the ones you'd like. Despite being a popular project, we have very few people voting on these issues . We can then use the link above (issues sorted by most thumbs up ), to keep track.

Thanks all.

you are viewing a single comment's thread
view the rest of the comments
[–] Zalamander@lemmy.ml 3 points 2 years ago (4 children)

I would be happy to see client-side password hashing implemented.

I understand that responsibility of using unique passwords falls on the user, and maybe a truly malicious instance would be able to remove the hashing (although I think that it would be possible to check if non-hashed passwords leave the client). However, the reality is that many people still re-use their password for many websites and do not use 2FA when not required. Password hashing would reduce the level of trust required of the instance makers.

On a similar vein, it would be nice to anonymize the ip addresses that are printed to the docker logs if possible, similar to the nginx logs. I think that this would be easier to undo for a malicious instance, but at least they would need to have a bit more technical knowledge to get to this information.

[–] dessalines@lemmy.ml 2 points 2 years ago (2 children)

The back-end already does password hashing using bcrypt.

[–] Zalamander@lemmy.ml 2 points 2 years ago (1 children)

This protects the database from a breach, but someone can set up an instance and collect the passwords from the logs:

As far as I can tell with my very limited experience, back-end encryption is the standard. One trusts the host not to steal their passwords from the logs, so protecting the data in the case of a breach is good enough. I think that it would make sense for the standard in the Fediverse to be different. Passwords should be encrypted by the client by default, and then re-hashed back-end.

It is also possible that what I am saying does not make sense in practical grounds - this is just something that surprised me while looking through the logs. I was under the wrong impression that plain text passwords were never accessible before looking into this topic.

[–] dessalines@lemmy.ml 3 points 2 years ago

We've recently removed that logging line, which logged all websocket requests. But yes most importantly, the database stores no plaintext passwords.

You don't want to client side hash passwords before sending, because different clients might not do it the same way. But also we have to add oauth at some point, so 3rd party clients don't even have to know your pass. This is less important with open source apps imo, which are the only ones we're gonna link to anyway, but it'd be nice to have.

load more comments (1 replies)