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"
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.