Tokenless REST API security concerns

Question

I'm designing an API in PHP/MySQL that, by its design, will not store a user's password in the database and thus does not generate authorization tokens for the client to hold. The reason for this is to prevent any possibility of sensitive, unencrypted information being obtained in the event of a database compromise.

The user's sensitive data is encrypted using their own password, so that the decryption of the data cannot be done with anything stored within the (potentially compromised) database. I've implemented some security features currently:

1. As previously described, the sensitive data is encrypted using AES using the user's SHA-512 hashed password (the password is provided with every request as form data), plus some extra salt.
2. HTTPS is required, and only POST requests are permitted.
3. User accounts are identified by e-mail addresses (trimmed and lower-cased in storage) and require verification before use.
4. User passwords are required to be a minimum of 8 characters long.
5. Eventually, an API token will be required for third-party app usage via the Authorization header. Third-party apps are restricted in that they cannot create, verify or delete accounts.

My question is, is this enough? I'm hardly a security expert and the last thing I want to do is design something with a major oversight. My main concern is the user's password being provided with every request, even though it would be only through SSL.

Edit:

To clarify, users will be able to change their passwords provided they still have their current one. A request is made containing the user's e-mail address, the current password, and the new password. The request is authenticated like it normally is, using the e-mail address and the current password. Validation is done on the new password (enforcing the 8-character minimum) as well, before continuing.

First, just as it's done when the user wishes to retrieve their sensitive information, the information is decrypted using their current password. In its decrypted state, the information is then encrypted using the new password, and the sensitive data is overwritten in the database.

At this point, there is no stored record of the previous password and it can no longer be used. A password change cannot be done by an administrator or, in any case, without the password that was used to previously encrypt the information. If the password is lost, then nothing can be done.

Answer 1

Your idea is not unreasonable. Encrypting a user's data using a key that can only be generated when the user is present is a reasonable tactic, and is in fact used in a number of high-security environments. This can provide significant safety if done right. But I would introduce the following caveats and modifications:

• Stateless authentication should be avoided. It's categorically worse than session-limited authentication. Yes, always. There are multiple reaons, but one of which is that if passwords are sent with every request, then passwords are cached somewhere. Ideally, the user should log in, which "unlocks" the datastore and gives the user a time-limited session key which can be used to access the "unlocked" datastore for a limited time only. This allows you to expire authentication sessions and helps prevent a number of potential attacks. Note that this requires a subtle design change that I'll detail below.

• If the client's data can be encrypted client-side, then do that. If all you ever see of the user's data is an encrypted blob of bits, then at no point could your server ever put that data at risk.

• You should consider using a two-step encryption chain. Rather than encrypting the user's data using the password-derived key, you should instead encrypt the valuable data using a totally random key, and then encrypt that totally random key using your user's password-derived key. This allows you to (a) easily change user passwords, (b) introduce more complex authentication schemes (e.g. two-factor), and (c) removes the requirement of sending the password with every request. Simply re-encrypt the datastore key using a temporary key which you derive from a random session token which you give to the user at login. You should also tie in the current time, user's IP, and any other session-specific information that you want to use to prevent sessions-stealing.

• Use a reasonable key derivation formula. A single pass of any hashing function is not sufficient to prevent an attacker from brute-forcing your encryption key if he gets the encrypted data. Instead, use a function like PBKDF2 or scrypt with a resonable number of rounds. This dramatically increases the amount of work an attacker would need to do to guess a user's password.

Answer 2

Before reinventing the wheel and building your own session manager, read the OWASP Session management Cheatsheet, which will help you avoid common mistakes.

The problem is that the proposed authentication token sha512(password) used to maintain the authenticated state, it is in fact a very understandable session token for a number of reasons:

1. The worst problem is that this proposed session id has a very small key space. It is lot easier for an attacker to guess sha512(password) than to guess 16 bytes of /dev/urandom.
2. Encryption != Authentication. Multiple keys can act upon cipher text to yield some result, only the correct key will actually yield the real plain-text. You still have to verify that you have received the exact key and AES-CBC won't do that. The correctness of this key could be verified with a hash function, a CMAC or HMAC. AES in an authenticated mode of operation would work.
3. CWE-613 states that session ids or "tokens" must expire. By using the password hash, in effect a new password has been created that is sha512(password) that doesn't expire and can be used to authenticate without knowing the plain-text password. Once this value is compromised an attacker can access the account.
4. SHA512 is bad Key Derivation Function (KDF) and a bad way to store passwords in general (CWE-916). bcrypt, pbkdf2, scrypt are all good options.
5. If you are being RESTful, then use the proper VERB! Using POST for everything is confusing. Enforcing POST doesn't make the system more secure, these requests are just as vulnerable as GET to attacks like CSRF or other attacks.