In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)

Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.

  • IphtashuFitz@lemmy.worldEnglish
    7·
    3 days ago

    Proper hashing of a password includes a salt that should be kept private. This means the password should definitely be passed to the server in plaintext. The server adds the salt to the password, then hashes it.

    This adds more protection should an attacker somehow manage to get access to your hashed passwords. Even if they identify the type of hashing mechanism used it will prevent the use of rainbow tables, dictionary attacks, etc. against the hashes.

    • Ziglin (it/they)@lemmy.worldEnglish
      1·
      7 hours ago

      If that were the case you could still hash it on the client side, forcing it to be a certain size and then hash it again on the server with the right salt. I don’t think there’s a real disadvantage to hashing a hash.

    • troed@fedia.io
      7·
      3 days ago

      While I’m not arguing for doing the crypto client side, the salt isn’t needed to be private - only unique.

      • IphtashuFitz@lemmy.worldEnglish
        3·
        3 days ago

        It definitely needs to be private. If an attacker can obtain both the password hashes and the salt(s) (via the same database vulnerability for example) then they have everything they need to run offline attacks against the passwords.

        • troed@fedia.io
          9·
          3 days ago

          No, it most definitely does not need to be private. The idea with salt is to invalidate rainbow tables. If you’re “keeping it private” it’s just another password.

          The salt and the password (or its version after key stretching) are concatenated and fed to a cryptographic hash function, and the output hash value is then stored with the salt in a database. The salt does not need to be encrypted, because knowing the salt would not help the attacker.

          https://en.wikipedia.org/wiki/Salt_(cryptography)

        • mic_check_one_two@lemmy.dbzer0.comEnglish
          2·
          3 days ago

          The salt is specifically to invalidate pre-generated rainbow tables, and doesn’t need to be kept private. It only needs to be unique.

          The attacker generates rainbow tables by running common passwords through known hashing algorithms. So I run “password1” through a bunch of different algorithms, and save the results of each. Notably, generating decently large rainbow tables takes a lot of time, processing power, and storage space. Because you don’t just use common passwords; You’re basically running a brute force/dictionary attack on your own computer’s hashing algorithm.

          Now if a database is unsalted, I can search for matching results against my rainbow table. When I see a match, it tells me both which users had that password and which hashing algorithm they were using. So now I can narrow down my focus to only using that algorithm.

          But if a database is salted, all of my pre-generated tables are useless. Even if someone used “password”, it won’t match my rainbow tables because the hash was actually fed “password{hash}” instead. And even if multiple users used “password”, each salt is unique, so I don’t see a bunch of repeated hashes (which would point to those accounts using the same password). I would now need to generate all new tables with the salts I stole in order for my rainbow tables to be usable again. And even then, I’d need to repeat that table generation for every user.