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.

  • troed@fedia.io
    0·
    12 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
      0·
      12 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
        1·
        12 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)