Save sensitive data in Actix session

Hello

When a user authenticates himself successfully I save the whole User-object in the session like this:

session.set("user", user.unwrap());

This is the User struct:

#[derive(Serialize, Deserialize, Clone)]
pub struct DistributorUser {
    id: u64,
    username: String,
    password: String,           // Also password (HASH) will be serialized !!
    distributor: Distributor,
    display_name: String,
}

But I wonder if this is safe, because the password will also be saved in the cookie. Everything is over HTTPS, but this still feels bad.

Solutions I have thought of to make it save.

  1. Skip serializing: I could do #[serde(skip_serializing)] so the password won't get serialized. But that often gives the error: thread 'actix-rt:worker:0' panicked at 'called `Result::unwrap()` on an `Err` value: Error("missing field `...`", line: 1, column: 366)', ... So I'm not a fan of this.
  2. Saving ID. I could also only save the ID of the user, and then get the user from the database each time it's needed, but this is time consuming.
  3. Saving session GUID. I could also save the session GUID in my session and make a database to link a session to a user. But this is too complicated.

What would be the best way to do this? Or is the way I do it already save? Thanks.

I would definitely not save the entire "User" struct. You could use skip rather than skip_serializing which will result in the password field being an empty string when loaded from session (it uses the default value if missing on deserialization instead of failing like it does with skip_serializing), but in this situation I personally would probably just create another struct that represents the information saved in the user browser.

I think it goes without saying, but just in case: You should also definitely to make sure to use the signed or private session types for this.

Also, I'd be a bit wary of that panic you did see with skip_serializing, since other inputs could potentially cause it. (Is it expected that if the cookie is signed, it must be valid?)

1 Like

If it were me I'd question the wisdom of keeping a password around at all. You shouldn't need anything but a hash in almost all cases. Validate the user then forget the password entirely.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.