Comment

Comment on Larion Studios forum stores your passwords in unhashed plaintext.

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.

source

Sort:hotnew top

RonSijm@programming.dev ⁨1⁩ ⁨year⁩ 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

source
- ilinamorato@lemmy.world ⁨1⁩ ⁨year⁩ 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?
  
  source
  - RonSijm@programming.dev ⁨1⁩ ⁨year⁩ 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
    
    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?
    
    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.
    
    source
    ilinamorato@lemmy.world ⁨1⁩ ⁨year⁩ ago
    Awesome. Thanks for the links and the info.
    
    source