• DreamButt@lemmy.world
    link
    fedilink
    English
    arrow-up
    25
    arrow-down
    8
    ·
    1 year ago

    In theory yes. But in practice the DB will almost always have some cap on the field length. They could just be exposing that all the way forward. Especially depending on their infastructure it could very well be that whatever modeling system they use is tightly integrated with their form generation too. So the dev (junior or otherwise) thought it would be a good idea to be explicit about the requirement

    That said, you are right that this is still wrong. They should use something with a large enough cap that it doesn’t matter and also remove the copy telling the use what that cap is

      • intensely_human@lemm.ee
        link
        fedilink
        English
        arrow-up
        15
        arrow-down
        4
        ·
        1 year ago

        Right but that puts a limit on the hash algorithm’s input length. After a certain length you can’t guarantee a lack of collisions.

        Of course the probability stays low, but at a certain point it becomes possible.

        • brygphilomena@lemmy.world
          link
          fedilink
          English
          arrow-up
          7
          ·
          1 year ago

          Collisions have always been a low concern. If, for arguments sake, I.hate.password. had a collision with another random password like kag63!gskfh-$93+"ja the odds of the collision password being cracked would be virtually non-existent. It’s not a statistically probable occurrence to be worried about.

        • __dev@lemmy.world
          link
          fedilink
          English
          arrow-up
          4
          arrow-down
          2
          ·
          1 year ago

          This is plainly false. Hash collisions aren’t more likely for longer passwords and there’s no guarantee there aren’t collisions for inputs smaller than the hash size. The way secure hashing algorithms avoid collisions is by making them astronomically unlikely and that doesn’t change for longer inputs.

    • BorgDrone@lemmy.one
      link
      fedilink
      English
      arrow-up
      23
      ·
      1 year ago

      You misunderstand the issue. The length of the password should not have any effect on the size of the database field. The fact that it apparently does is a huge red flag. You hash the password and store the hash in the db. For example, a sha256 hash is always 32 bytes long, no matter how much data you feed into it (btw, don’t use sha256 to hash passwords, it was just an example. It’s not a suitable password hashing algorithm as it’s not slow enough).

      • DreamButt@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        1
        ·
        1 year ago

        ur absolutely right. Idk why I was thinking about it like a normal text/char field