We’ve all been there.

  • PeeJay@lemmy.world
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    1
    ·
    edit-2
    1 year ago

    That’s just not true, all of these things can be achieved without saving the password as plain text

    • unixfreak@feddit.uk
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      1 year ago

      How is it not true? If a site is saying for example, “password must be less than 20 characters” – that is purely a limitation based on the size of the database field, which you can only assume it’s being adding to that field as plain text. A hash will always be the same length and password length would not matter.

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

        I’ll keep my aswer short, but first of all, usually this format enforcement is done on the client before it is ever sent to the backend, there are many reasons to limit the maximum length other than string length limitations on the database ( not that I can think of many actual good reasons).

        Second of all, the client should send the actual password to the backend (allowing you validate these same password requirements on your backend), not the hashed password, hashing the password on the client side would be no better than storing the password as “plain text”.

        And never is the “plain text” password stored in any database, only sent over to the backend and hashed, every time you set a new password, or log in using an existing one.