I have a client-server-system and I need to send a password from the client to the server. I hash the password on the client side (with a salt) and then send the hash to the server. Is that enough or do I need to do more?

  • 5
    Is there no built-in https/tls option?
  • 4
    The "salt" that you use should be given by the server, and it should change every time so that no replay attack is possible. Challenge / response style.

    To avoid storing the password on the server, that whole show shouldn't operate on the password directly, which shouldn't be on the server, but on whatever the server has stored (salted hash).
  • 8
    1. Transport encryption (TLS). If you don't do this in 2020, you are doing something wrong.
    2. Hashing server side, and not just "with a salt", but with a proper password hashing function (argon2, bcrypt, pbkdf2), they also do salt generation as well.
    Why server and not client side?
    The salt must leave the database (not that bad) and you ate creating password equivalent (e.g. I can login with the password hash instead of the password). In the Windows world, such attack is known as "pass-the-hash".
  • 1
    @alexbrooklyn @Fast-Nop It's a personal project, server and client are both in my home network and the only users are going to be my family members so security isn't that important. I just wanted to know if I understood the concept correctly. Thanks for the advice.
  • 1
    @sbiewald I'm probably going to use TLS in the future, but at the moment I don't think I need it. So I should hash on client and server side or just server side?
  • 2
    @Sh4d0w You can even encrypt the content by using the salted hash (stored on the server and derived from the password on the client) together with the session challenge as password for the connection.

    For toying around at home, why not.
  • 1
    @Sh4d0w Just server side is enough (you can do both, but the security improvement is not that much).
  • 0
    Open-ssl is you best bet , but i am not sure in all the details that you are working with.
  • 1
    Never trust the network. Not at work and not at home. Encrypt all the things all the time. TLS is cheap.

    And if it is for a limited user base, just go with self-signed client and server certificates. That way, your family does not need to enter any passwords after you initially configured their browsers to trust the server cert and use the corresponding client cert to identify themselves.
  • 0
    @Fast-Nop what's your opinion on PostgreSQL's pgcrypto extension (for password hashing)?
  • 1
    @chabad360 I don't have an informed opinion on that.
  • 0
    Maybe @sbiewald? What do you know about PostgreSQL's pgcrypto extension?
  • 1
    @chabad360 @Fast-Nop It is described here: https://postgresql.org/docs/8.3/...

    From my view, if blowfish is used in crypt(password text, salt text), you should be fine.
  • 1
    @sbiewald Blowfish is an encryption algorithm, not a hashing one (IIRC). For hashing, I'd go e.g. with SHA512, and multiple rounds of that.
  • 0
    @Fast-Nop would blowfish be ok tho (it's the best pgcrypto supports...)?
  • 0
    @chabad360 I don't think so because you want a hashing algorithm while Blowfish is an encryption algorithm.
  • 2
    @Fast-Nop Of course, I just misread it.
    They refer to bcrypt as blowfish multiple times.
  • 0
    @sbiewald wait, really?
  • 1
    @chabad360 Table F-18. Supported algorithms for crypt(): bf ... Blowfish-based, variant 2a.

    This only makes any sense if they refer to the bcrypt hashing algorithm, not the blowfish block cipher.
  • 0
    @sbiewald ah, makes sense. I'm no crypto expert, so I kind of just take that stuff at face value (although I do recall being slightly surprised that blowfish was also for hashing).

    At some point is the near future I'll probably need to read up more on this, but for now I should be fine. Yay.
Add Comment