Fix send password handling

[Hinton]

Type of change

- [x] Bug fix
- [ ] New feature development
- [ ] Tech debt (refactoring, code cleanup, dependency upgrades, etc)
- [ ] Build/deploy pipeline (DevOps)
- [ ] Other

Objective

We should hash send passwords appropriately using pbkdf. Also changed how SendView handles passwords. It no longer provides the password but rather a boolean field has_password to prevent accidentally overriding the password when doing send.decrypt().encrypt().

Before you submit

• Please add unit tests where it makes sense to do so

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (339f45e) 49.34% compared to head (2c8ef50) 49.51%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #493      +/-   ##
==========================================
+ Coverage   49.34%   49.51%   +0.17%     
==========================================
  Files         154      154              
  Lines        7373     7398      +25     
==========================================
+ Hits         3638     3663      +25     
  Misses       3735     3735              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dani-garcia]

Hmm, this works but I think it would be clearer if we separated the password hashing to a different function and left the encrypt/decrypt to just do encryption.

We can even have a HashedPassword newtype to avoid people accidentally passing an unhashed password. What do you think?

let password: HashedPassword = client.kdf().hash_send_password(password);
let send = Send {
    password,
    ....
};
// Now in decrypt/encrypt we can just pass the field around without modifying it.
send.encrypt().decrypt();

[Hinton]

@dani-garcia There are some more nuances to this. The server will also hash the password. The server response for the password field is actually serverHashed(clientHashed(password)).

If on encrypt we respond with serverHashed(clientHashed(password)) it may accidentally be sent directly to the server meaning it will be re-hashed and end up as serverHashed(serverHashed(clientHashed(password))).

My desire with the current approach was to completely eliminate the possibility of calling view.encrypt() and uploading it to the server without first removing send.password.

[dani-garcia]

Ah fair enough, I forgot about the server side hashing, maybe there's something we could do with an enum like enum SendPassword { NoPassword, AlreadySet, New(String) }, but maybe that won't translate very nicely to the mobile bindings.