Think back to the last time you looked at an unfamiliar block of code. Did you immediately understand what it was doing? If not, you’re not alone – many software developers, including myself, find it challenging to grasp unfamiliar code quickly…
It’s unclear, but quite likely that the type has changed here. Even in a duck typed language this is hard to manage and often leads to bugs.
Even without a type change, you shouldn’t reuse an object member like this. Dramatically better to have password and hashed_password so that they never get mixed up. If you don’t want the raw password available after this point, zero it out or delete it.
All of these style considerations apply 4x as strongly when it’s a piece of code that’s important to the security of your service, which obviously hashing passwords is.
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.
I agree. The field shouldn’t have been called ‘password’ in the first place, but rather ‘plaintextPassword’ or similar. That makes the code much more readable, if at a glance I know if I’m dealing with the hash or the plaintext version.
In addition to the excellent points made by steventhedev and koper:
Just this one line of code alone is wrong.
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.
I absolutely agree. An even better structure wouldn’t have a raw password field on the user object at all.
I agree. The field shouldn’t have been called ‘password’ in the first place, but rather ‘plaintextPassword’ or similar. That makes the code much more readable, if at a glance I know if I’m dealing with the hash or the plaintext version.