Putting a password in a REST API call

Question

Suppose I have a REST API that is also used to set/reset passwords. Let's also suppose that this works over a HTTPS connections. Is there any good reason not to put that password in the call path, let's also say I will encode it in BASE64?

An example would be to reset a password like this:

http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD

I understand BASE64 is no encryption, but I only want to protect the password to shoulder surfing in this case.

Answer 1

A good server logs all requests sent to it, including URLs (often, without variable part after '?'), source IP, execution time... Do you really want this log (potentially read by a wide group of admins) to contain critically secure info as passwords? Base64 isn't a stopper against them.

Answer 2

What you are proposing is neither secure nor RESTful.

@Netch has already mentioned the issue with logs, but there is also another issue in that you are showing passwords being sent by HTTP, making it trivial to capture passwords with any sort of wire sniffer or man-in-the-middle attack.

When you do a GET request using REST, the different elements in the URL represent more fine grained elements. Your URL reads like you are returning a NEWPASSWD part of an OLDPASSWD that's part of a resetpassword. That does not make any sort of semantic sense. GETs should not be used to save data.

You should be doing something like this:

POST https://www.example.com/user/joe/resetpassword/
{oldpasswd:[data], newpasswd:[data]}

POST because you are writing data, and https because you don't want it sniffed.

(This is really the low-bar security. The absolute minimum you should do.)

Answer 3

The proposed scheme has issues in several areas.

Security

URL paths are frequently logged; putting unhashed passwords in the path is poor practice.

HTTP

Authentication/authorization information should appear in the Authorization header. Or potentially, for browser-based stuff, the Cookie header.

REST

Verbs such as resetpassword in your URL are generally a clear sign of a non-representational state transfer paradigm. A URL should represent a resource. What does it mean to GET resetpassword? Or DELETE?

API

This scheme requires always knowing the previous password. You will probably want to allow for more cases; e.g. the password is lost.

---

You could use Basic or Digest authentication, which is are well understood schemes.

PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: text/plain
Host: www.example.com

NEWPASSWD

It doesn't put ultra-sensitive information in the path, and it follows HTTP and REST conventions.

If you needed to allow for some other mode of authorization (e.g. some token sent through a verified channel to reset the password), you can simply use a different Authorization header without having to change anything else.

Answer 4

The problem is to avoid plain text passwords in your requests. There are two options to fulfill the restful webservice requirements.

1. Client side hashing

• I'll guess you are storing your passwords like e. g. hash(password+salt)
• You can hash the new password with a salt on the client side
• That means: Create a new salt on the client side, create a hash e. g. hash(newPassword+newSalt)
• Send the new created hash plus the salt to your restful webservice
• Send the old password also as hash(oldPassword+oldSalt)

2. Encryption

• Create a "one time key" (otk) resource for a user like /otk/john
• This resource returns an secure random unique one time key, e. g. kbDlJbmNmQ0Y0SmRHZC9GaWtRMW0ycVJpYzhMcVNZTWlMUXN6ZWxLdTZESFRs and a unique ID e. g. 95648915125
• Your restful webservice has to store this random otk for the next secure communication with the ID 95648915125
• Encrypt your new and old password with the otk e. g. AES (for security reasons you should use two separate otks for the old and new password)
• Send the encrypted passwords to your change password resource with the ID 95648915125
• One otk and ID combination is allowed to work once only, so you have to deleted that combination after chaning the password
• Possible better option: Send the current/old password by Basic-Auth.

Note: HTTPS is required for both options!

Answer 5

Apart from security, the problem with this is that it isn't a very RESTful approach.

OLDPASSWD and NEWPASSWD don't stand for anything in your resource hierarchy and even worse, the operation isn't idempotent.

So you can only use POST as your verb, and you should not include the two passwords in your resource path.

Answer 6

What are the features of a password-reset operation?

1. It change something.
2. There is a value that it is set to.
3. Only some people are allowed to do it (the user, an admin, or either, perhaps with different rules as to how either can do so).

Point 1 here means you cannot use GET, you must either POST something representing the password-change operation to a URI representing a resource that handles password changes, or PUT something representing the new password to a URI representing the password or representing something (e.g. the user) of which that password is a feature.

Generally we'd POST, not least because it can be awkward PUTting something we can't later GET and of course we can't GET the password.

Point 2 therefore will be data representing the new password, in what is POSTed.

Point 3 means we'll need to authorise the request, which means that if the user is the current user we'll need the current password to be proven to us (though not necessarily receive the current password, if e.g. a hash-based challenge was used to prove knowledge of it without sending it).

The URI should therefore be something like <http://example.net/changeCurrentUserPassword> or <http://example.net/users/joe/changePassword>.

We might decide that we want to receive the current password in the POST data as well as in the general authorisation mechanism being used.