• Aijan@programming.devOP
    link
    fedilink
    arrow-up
    0
    ·
    14 days ago

    I appreciate the security concerns, but I wouldn’t consider overriding the password property with the hashed password to be wrong. Raw passwords are typically only needed in three places: user creation, login, and password reset. I’d argue that having both password and hashedPassword properties in the user object may actually lead to confusion, since user objects are normally used in hundreds of places throughout the codebase. I think, when applicable, we should consider balancing security with code maintainability by avoiding redundancy and potential confusion.

    • nous@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      14 days ago

      When is the hashed password needed other than user creation, login or password resets? Once you have verified the user you should not need it at all. If anything storing it on the user at all is likely a bad idea. Really you have two states here - the unauthed user which has their login details, and an authed user which has required info about the user but not their password, hashed or not.

      Personally I would construct the user object from the request after doing auth - that way you know that any user object is already authed and it never needs to store the password or hash at all.

      • Aijan@programming.devOP
        link
        fedilink
        arrow-up
        0
        ·
        14 days ago

        Perhaps I was unclear. What I meant to say is that, whenever possible, we shouldn’t have multiple versions of a field, especially when there is no corresponding plaintext password field in the database, as is the case here.

    • Atlas_@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      14 days ago

      I absolutely agree. An even better structure wouldn’t have a raw password field on the user object at all.