Added journalist password change API

[mdrose]

Status

Ready for review / Work in progress

This is only the API call for password changes. I haven't done 2FA yet.

Unit tests are included.

Description of Changes

Changes are in response to #3869

Testing

API endpoint is /api/v1/user/new-passphrase

The new password is specified in the "new_passphrase" attribute in the JSON data.

[redshiftzero]

this is looking super good so far @mdrose! dropped some notes inline

[redshiftzero]

what happens if new_password is not found in the request body?

(any expectations like this for the request body that might not be valid are good test cases to add)

[mdrose]

New commit adds checks for missing request parameters and invalid data types, along with relevant tests.

[redshiftzero]

currently we have an /user endpoint which gets information about the current user, what about making this new endpoint /user/new-passphrase instead of /account/new-password?

another thought: we should also add a link to this in the response from the /user endpoint:

{
  "is_admin": true,
  "last_login": "2018-07-09T20:29:41.696782Z",
  "username": "journalist",
  "uuid": "a2405127-1c9e-4a3a-80ea-95f6a71e5738",
  "new_passphrase_url": "/user/new-passphrase"
}

[mdrose]

Done

[redshiftzero]

on the regular journalist interface for journalist passphrase reset, we have two additional requirements (for defense in depth) which is to provide a valid passphrase and 2FA token before changing the passphrase. additionally, we have the web application generating the diceware passphrases both for sources and journalists (shown only in the session where they are generated/changed). we should do the same here in the API too.

recapping - the logic should be:

1. client sends request to this endpoint with old_passphrase and two_factor_code in the body
2. server checks they are valid
3. server generates a diceware passphrase and provides the user a new_passphrase in the response

[heartsucker]

This is dangerous because if a client doesn't finish the read (broken connection), then the client could be locked out. Changing a passphrase should require multiple steps.

1. Client requests new passphrase
2. Server check auth, sends new passphrase, and stores new_passphrase_hash or something in the DB
3. Client replies with the new passphrase to confirm (separate endpoint)
4. Server checks the request matches the new hash them moves it over in the db
5. Server responds that the passphrase has changed

Additionally, errors in the client (failure to display passphrase, crash, etc) could mean that at the network level, everything went just fine, but the user is still locked out.

Because this is happening over Tor, we have to plan for exceptional robustness.

[mdrose]

@redshiftzero:

3. server generates a diceware passphrase and provides the user a new_passphrase in the response

@heartsucker:

2. Server check auth, sends new passphrase, and stores new_passphrase_hash or something in the DB

So, currently, the web interface basically offers a new password suggestion, which doesn't get stored in the database. It's still up to the client to send a new password, which then gets validated against criteria (length / words).

[heartsucker]

This is dangerous because if a client doesn't finish the read (broken connection), then the client could be locked out. Changing a passphrase should require multiple steps.

1. Client requests new passphrase
2. Server check auth, sends new passphrase, and stores new_passphrase_hash or something in the DB
3. Client replies with the new passphrase to confirm (separate endpoint)
4. Server checks the request matches the new hash them moves it over in the db
5. Server responds that the passphrase has changed

Additionally, errors in the client (failure to display passphrase, crash, etc) could mean that at the network level, everything went just fine, but the user is still locked out.

Because this is happening over Tor, we have to plan for exceptional robustness.

[heartsucker]

I would also suggest that all 500 errors on this endpoint use the same string to not give additional information to an attacker.

[mdrose]

Done

[heartsucker]

Ok so this isn't a complaint about anything here being wrong, but I wrote a kinda-equivalent to WTForms for JSON just so that this could be extracted away from the endpoints (moved into classes) and still provide clear, sensible error messages.

https://github.com/heartsucker/python-json-serde

I know we don't want to add a lot of dependencies here, but this (or a cleaned up, slightly better version) might add to less hand written code in the app and make everything a little cleaner.

[mdrose]

Yeah, obviously this should probably be refactored in some form for use in other endpoints. As you said, there's certainly libraries that do this sort of stuff, if we're ok with another dependency.

There's many out there. I know there's WTForms style implementations out there, like yours. There's also JSON Schema implementations, like this: https://github.com/Julian/jsonschema etc.

Regardless, the API endpoint will still have to define the data it expects, so, I think it also depends on how complicated the API schema gets and how complicated it is to validate. Right now it's pretty simple, but, obviously, that can change.

[heartsucker]

I used to work at a company that tried to define all its messages with JSONSchema, and it was horrible because of the complexity. I would really rather not use it because things that can be expressed in a couple of lines of code / sentences became super unwieldy in JSONSchema.

[mdrose]

I'm not really attached to any of these and there's just so many (Marshmallow and Schematic also come to mind).

There are advantages to serialized schemas (like JSON Schema), though. You can keep the server and client in sync better, with fewer modifications / duplication client side, since the client can just react to the server's schema.

Anyway, the current messages are pretty simple and I don't know if we need the complexity / external dependency of this kind of stuff right now, but I don't know the roadmap for this project in terms of future functionality.

Regardless, just let me know how you guys would like me to proceed and I'll adjust this PR accordingly.

[eloquence]

Hi @mdrose, sorry for the long silence on this PR. Just a note that we're still interested in landing this change -- the main reason we've not looked at it is simply that the SecureDrop Client, which is the main consumer of this API, currently does not expose any account management features, and it's not been a very high priority for beta users to add such features, because they are so rarely used.

That said, we will begin working on performance improvements and new features for the API later this year (#5104). Ideally, the SecureDrop Client should enable a journalist user to do everything they can do through the web UI, so this is still a candidate for the next round of API improvements. We'll revisit the work you've done here in that context.

Thanks again for working on this!