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

• beefcat@lemmy.world ⁨1⁩ ⁨year⁩ 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

  source

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

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

    source

    • beefcat@lemmy.world ⁨1⁩ ⁨year⁩ ago

      but then you expose your salt to the public

      source

      • RonSijm@programming.dev ⁨1⁩ ⁨year⁩ ago

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

        source
    • ilinamorato@lemmy.world ⁨1⁩ ⁨year⁩ 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.

      source

      • 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

        • -> View More Comments
• oneiros@lemmy.blahaj.zone ⁨1⁩ ⁨year⁩ ago

  Stored in memory is still stored.

  Given what I know about how computers accept user input, I am fascinated to hear what the alternative is.

  source

  • Cabrio@lemmy.world ⁨1⁩ ⁨year⁩ ago

    You have the text input feed directly into the encryption layer without an intermediary variable.

    source

    • frezik@midwest.social ⁨1⁩ ⁨year⁩ ago

      Are you suggesting to do all this on the frontend before it goes to the backend?

      source

      • Atomic@sh.itjust.works ⁨1⁩ ⁨year⁩ ago

        If they can send you, your own password in plain text. That’s already bad enough. Just the fact that they have stored your plaintext password somewhere is bad.

        The way it should be handled is them never knowing your plaintext password and therefore be forced to send you a new temporary password, and make you change it upon logging in.

        source
      • Cabrio@lemmy.world ⁨1⁩ ⁨year⁩ ago

        The front end to backend traffic should be encrypted, hashing occurs on the backend. The backend should never have access to a variable with a plaintext password.

        source

        • -> View More Comments