476
submitted 2 years ago by Cabrio@lemmy.world to c/games@lemmy.world

Larion Studios forum stores your passwords in unhashed plaintext. Don't use a password there that you've used anywhere else.

you are viewing a single comment's thread
view the rest of the comments
[-] beefcat@lemmy.world 33 points 2 years ago* (last edited 2 years ago)

there is no possible way to handle sensitive data without storing it in memory at some point

it’s where you do all the salting, hashing, and encrypting

emailing out credentials like this after sign up is certainly not best practice, but probably not a huge deal for a video game forum of all things. if you are re-using passwords then you already have a way bigger problem.

[-] JackbyDev@programming.dev 14 points 2 years ago

emailing out credentials like this after sign up is certainly not best practice,

Understatement of the year right here. Everyone in this thread is more interested in dunking on OP for the few wrong statements they make rather than focusing on the fact that a service is emailing their users their password (not an autogenerated "first time" one) in plaintext in an email.

[-] RonSijm@programming.dev 4 points 2 years ago

there is no possible way to handle sensitive data without storing it in memory at some point

Since we're nitpicking here - technically you can. They could run hashing client side first, and instead of sending the password in plain-text, you'd send a hashed version

[-] beefcat@lemmy.world 2 points 2 years ago

but then you expose your salt to the public

[-] RonSijm@programming.dev 2 points 2 years ago

No, the client side hashing doesn't substitutes anything server side, it just adds an extra step in the client

[-] ilinamorato@lemmy.world 1 points 2 years ago

This opens up the possibility of replay attacks in the case of data breaches, though, and those are much more common than http mitm attacks (made even less likely with the proliferation of https).

I'm not entirely sure whether hashing twice (local and server) is wise, having not thought through that entire threat vector. Generally I try to offload auth as much as I can to some sort of oauth provider, and hopefully they'll all switch over to webauthn soon anyway.

[-] RonSijm@programming.dev 1 points 2 years ago

I'm not really sure how it opens up replay attacks, since it doesn't really change anything to the default auth. There are already sites that do this.

The only difference is that instead of sending an http request of { username = "MyUsername", Password = "MyPassword" } changes to { username = "MyUsername", Password = HashOf("MyPassword") } - and the HashOf("MyPassword") effectively becomes your password. - So I don't know how that opens up a possibility for replay attack. There's not really any difference between replaying a ClearText auth request vs an pre-hashed auth request. - Because everything else server side stays the same

(Not entirely auth related), but another approach of client side decryption is to handle decryption completely client site - meaning all your data is stored encrypted on the server, and the server sends you an encrypted container with your data that you decrypt client side. That's how Proton(Mail) works in a nutshell

[-] ilinamorato@lemmy.world 1 points 2 years ago

I'm not really sure how it opens up replay attacks

Put simply, jt allows an attacker with a leaked database to use the hashed password as a password. In your original comment, it seemed like you were suggesting hashing only before transmission, on the client; but hashing both before and after would indeed patch that particular vulnerability. I don't know if there are potential problems with that strategy or not.

another approach of client side decryption is to handle decryption completely client site

Here's potentially an opportunity for me to learn: how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it's sending? Since you can't count on a web browser to have the private key, do you send down an encrypted private key that can only be decrypted with the user's password? Is there some other way to do this that I'm not aware of?

[-] RonSijm@programming.dev 2 points 2 years ago* (last edited 2 years ago)

In your original comment, it seemed like you were suggesting hashing only before transmission

Ok, that wasn't what I was suggesting, no. That would effectively make your password hash the password itself - and it would kinda be stored in PlainText on the server, if you skip the client auth and send that value to the server directly through the api or something

how does such a service (like Proton Mail) perform this in a web browser without having access to the data necessary to decrypt all of the data it’s sending? [...] do you send down an encrypted private key that can only be decrypted with the user’s password?

Yes, pretty much. I can't really find a good, detailed explanation from Proton how it exactly works, but LastPass uses the same zero-knowledge encryption approach - which they explained with some diagram here - with a good overview of the client/server separation of it's hashing.

[-] ilinamorato@lemmy.world 1 points 2 years ago

Awesome. Thanks for the links and the info.

this post was submitted on 28 Sep 2023
476 points (100.0% liked)

Games

39591 readers
978 users here now

Welcome to the largest gaming community on Lemmy! Discussion for all kinds of games. Video games, tabletop games, card games etc.

Rules

1. Submissions have to be related to games

Video games, tabletop, or otherwise. Posts not related to games will be deleted.

This community is focused on games, of all kinds. Any news item or discussion should be related to gaming in some way.

2. No bigotry or harassment, be civil

No bigotry, hardline stance. Try not to get too heated when entering into a discussion or debate.

We are here to talk and discuss about one of our passions, not fight or be exposed to hate. Posts or responses that are hateful will be deleted to keep the atmosphere good. If repeatedly violated, not only will the comment be deleted but a ban will be handed out as well. We judge each case individually.

3. No excessive self-promotion

Try to keep it to 10% self-promotion / 90% other stuff in your post history.

This is to prevent people from posting for the sole purpose of promoting their own website or social media account.

4. Stay on-topic; no memes, funny videos, giveaways, reposts, or low-effort posts

This community is mostly for discussion and news. Remember to search for the thing you're submitting before posting to see if it's already been posted.

We want to keep the quality of posts high. Therefore, memes, funny videos, low-effort posts and reposts are not allowed. We prohibit giveaways because we cannot be sure that the person holding the giveaway will actually do what they promise.

5. Mark Spoilers and NSFW

Make sure to mark your stuff or it may be removed.

No one wants to be spoiled. Therefore, always mark spoilers. Similarly mark NSFW, in case anyone is browsing in a public space or at work.

6. No linking to piracy

Don't share it here, there are other places to find it. Discussion of piracy is fine.

We don't want us moderators or the admins of lemmy.world to get in trouble for linking to piracy. Therefore, any link to piracy will be removed. Discussion of it is of course allowed.

Authorized Regular Threads

Related communities

PM a mod to add your own

Video games

Generic

Help and suggestions

By platform

By type

By games

Language specific

founded 2 years ago
MODERATORS