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
    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.