I am writing a User Management system that has to include a change of password utility. We don't front end hash passwords (hopefully we will soon). As a result passwords are passed over https in the clear whenever a user is edited or his password is changed. Is there any difference in using "PUT" vs. "POST" requests in this use case. I would typically use "PUT" because it is a replacement/edit but I know for authentication the standard is "POST"
Asked
Active
Viewed 1.5k times
10
-
1"Over https in the clear" sounds paradoxical :) – Jack Jul 22 '14 at 11:00
-
@Jack I am new to security but I thought in the clear referred to unhashed – ford prefect Jul 22 '14 at 13:19
-
@Jack, Depends on the location of the man-in-the-middle he can mitm certain requests/responses send over https in the clear. – Pacerier Dec 11 '14 at 09:08
-
@Pacerier I don't see how that's at all relevant. – Jack Dec 11 '14 at 10:24
-
@Jack, Well you stated "Over https in the clear" sounds paradoxical, so I stated that it isn't. – Pacerier Dec 12 '14 at 02:42
-
@Pacerier What you've actually stated is that you didn't bother looking 'paradox' up in a dictionary :P – Jack Dec 12 '14 at 03:07
1 Answers
13
The PUT HTTP verb is supposed to be idempotent, a smart word meaning that sending twice the request should not have any further effect. The idea is that a "PUT" command is the opposite of "GET": the data contents sent with a "PUT" are supposed to be stored at the specified URL, and may conceptually be obtained back from that same URL with a "GET". In that respect, PUT and GET mimic the expected behaviour of FTP.
On the other hand, a "POST" is the generic verb for API-like calls: orders sent to a server for immediate execution. Such API calls are not idempotent. A "change password" call should probably be envisioned as an API call, not a file transfer. Therefore, you should use POST instead of PUT.
See for instance this blog post for further discussion about PUT vs POST.
From a security point of view, there is no real difference between PUT and POST: everything goes through the SSL, and it is mostly a matter of convention between client and server. As long as the client and server understand each other, then the security offered by both requests is the same.
The theoretical difference is that a client might take upon itself to issue a PUT call again in case of network failure, while it would not for a POST. Generally, you prefer the POST semantics, and keep PUT only for bulk file transfer where such reemission would be a nice feature, and not a problem.
-
So you are saying that the safest method of HTTP transport is via POST among all the possible methods? What about `PATCH` ? – Pacerier Dec 11 '14 at 09:10
-
Thank you @Tom Leek. Superb Description. Facing same issue but you are the Hero. – Mihir Oza Apr 26 '16 at 12:00
-
-
some password policies don't allow to set the same password twice. so in a put scenario a second call might result in an error, which is not real idempotent and could cause unwanted effects. – snap Jul 16 '20 at 09:34