Providing a patrons user password upon creating a patron

[bic-org-uk]

Providing a patrons user password upon creating a patron

[franciscave]

We could add a password element to the Patron entity, but if we do, we should make it clear that it is only valid to include it in the payload of a request to create (or modify?) a Patron entity, and should never be served in a response. If we were to use the Modify Patron entity function to change a patron's password, we would probably need to add an old-password element as well. But I feel I'm straying into areas of system security where I don't really have expertise. What do others think?

[anthonywhitford]

Security over passwords is extremely important. It is the password itself that must be protected, far more than the system the password grants access to, since users commonly use the same or similar passwords for unrelated systems. Therefore compromise of one password may inadvertently grant access to multiple systems to the hacker.

We should therefore allow the supply of a new password, but never allow any process to hint at retrieval of a password.

It may be a better solution to allow the HTTP POST & PUT of a password on a sub-url to the patron, eg.. /lcf/v1.0/patrons/{patron-id}/password

This would mean the XML schema did not contain any element where a password would be expected, and the use case of setting a password or changing a password could be delivered easily.

[mdovey]

Doesn't this fall foul of the same issue as in #19 viz the url being recorded in the logs of a perimeter proxy\firewall\load balancing server.

[franciscave]

As I understand it, the URL would not contain the password, as this would be in the entity supplied with the POST or PUT, not in the URL. All that can be derived from the log is the fact that a password has been created or updated, and not the password itself. Is that right?

[mdovey]

I was referring to Antony's suggestion above viz "It may be a better solution to allow the HTTP POST & PUT of a password on a sub-url to the patron, eg.. /lcf/v1.0/patrons/{patron-id}/password

This would mean the XML schema did not contain any element where a password would be expected"

[franciscave]

At the Technical Panel meeting on 22/09/2016 it was agreed that it should be possible to supply a new patron password in the payload of an HTTP POST or PUT request, as a non-XML payload (i.e. in a plain text MIME part) attached to the request as suggested by Anthony. We didn't agree what the response would contain, but I assume that this would be the standard HTTP response to a POST or PUT, indicating success or failure. I think this needs to be added to the LCF v1.0,.1 specification as a new function "Set Patron Password", which I'll add as new function 17.

It is my understanding that this would be the only way of setting a Patron password, as the Patron password is not a field that would ever be supplied or retrieved as part of a Patron record/entity.

[franciscave]

I have added function 17 to both the LCF v1.0.1 specification and to the REST Web Service specification. I have not formally specified how the password should be represented in the XML payload of a PUT request to set/reset, although I have added a recommendation to the REST Web Service specification that the XML payload should contain an element containing the password as an encrypted string. Does anyone think this needs to be specified more formally?

[anthonywhitford]

Hi Francis, that's not what was agreed and detailed in the previous comment?

[franciscave]

Oh, sorry. I mis-read my own comment! You're right, it should be a plain text MIME part, in which case I presume that the only thing in that MIME part is the encrypted password. Correct?

[franciscave]

I've tweaked the REST Web Service specification accordingly. I'm now wondering whether function 17 can use a POST as an alternative to a PUT. My gut feeling is that a PUT is more RESTful, but I'm not a REST expert, so may be wrong about this.

[mdovey]

Technically, POST should be used to create a new password, and PUT to update\modify an existing password.

POST would only really make sense for a newly created account which didn't yet have a password. PUT makes more sense if this is used for updating\resetting an existing password.

However, this does raise a question about the security of this function. How do we ensure that the patron has authorised the use of this function to change the password? The obvious solution is that the patron must authenticate, but this is only possible if the patron knows their password, i.e. this function could not be used to reset a forgotten password, nor (more importantly) used in the original scenario - to set a password for a newly created account.

[franciscave]

I've further tweaked the documentation to specify POST for setting the patron password the first time, and PUT for resetting it. I hope that's right...