Account creation API vulnerable to 'pre-populate' attack

[st3fan]

This is an attack scenario to think about:

I know that victim alice@example.com is going to setup an account in the future. So what I do is just make a call to POST /v1/accounts/create in her name and provide passwordStretching parameters that are in my advantage.

Alice will get an email to verify her account. But wether she ignores that email or acts on it is not important. The server will keep her (bad) initial settings around.

• I can set the number of PBKDF2 rounds to a very low value (like 1, 1)
• I can tune the Scrypt parameters to the lowest acceptable values that make it easier to attack (2, 1, 1)

When Alice resets her account, the SRP salt and verifier are regenerated since those are based on the password. But the other parameters stay unchanged. (As far as I can see in my limited testing with available tools. Please double verify this!)

Some things that can be done to mitigate this:

• The server should reject bad (low) values for PBKDF2 and Scrypt
• If the above cannot easily be done then the client must be forced to submit the PBKDF2 and Scrypt parameters again as part of the password recovery APIs.

[warner]

hm, good point. I remember thinking that "orphaned" accounts like this (which don't get verified for a long time) should really get deleted after a while, and that is probably ok w.r.t. Sync (which will refuse to sync anything until the email-is-verified flag gets set, providing a significant incentive to finish that task), but maybe less ok w.r.t. the other uses of an account.

I'm not sure if we do this now, but if we reset the password (where we don't know the old password at all, and are deleting the class-B data), I think we should use the client's preferred parameters and ignore whatever the server suggests. The change-password flow (where we do know the old password, and we retain class-B data) could arguably stick with the old parameters, or ignore them and use the client's current preferences.

(another exercise is to check whether a malicious server could convince a password-changing client to use weaker stretching for the new password. the server can deliver lower parameters, but then the client's password wouldn't match during SRP, and the question is whether the client will notice this or not before submitting the new less-stretched password. my hunch is that the difference in session keys means the client will get a random AccountResetToken, which the server won't know, and thus won't be able to decrypt the new srpVerifier)

[dannycoates]

The server should reject bad (low) values for PBKDF2 and Scrypt

This is fixed in #403 on /v1/account/create

When Alice resets her account, the SRP salt and verifier are regenerated since those are based on the password. But the other parameters stay unchanged.

Alice is allowed to submit new passwordStretching parameters to /v1/account/reset see https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#post-v1accountreset but I don't know if any client libraries use that capability.