Check auth for SRU

[HirschSt]

to get unpublished sources into the response

[HirschSt]

Maybe we can take the db user.encrypted_password as auth token and restrict the libraries, after selecting the user? Then no additional work for authentication should be necessary.

Example:

https://beta.rism.info/sru?version=1.1&operation=searchRetrieve&recordSchema=marc&query=rism.siglum==D-HR+AND+dc.author==Rosetti&x-info-2-auth1.0-authenticationToken=%$2a$11$yMMbLgN9uY6J3LhorfU9iuLAUwKxyy8w42ubeL4MWy7Fh8B.CH/yO%22

[ahankinson]

Do you know what method of encryption is used? Some methods produce the same output for the same input, which means the auth token is the same.

It anyway seems to me to be a bad idea to expose a users password hash in plaintext over the public internet.

[fjorba]

Doesn't the s in https effectively hide (encrypt) this communication, so it is not publicly available, even sniffing the traffic? Unless, of course, this url is made public as such.

[ahankinson]

It’s still not a good idea. MITM attacks, browser phishing, and even simple bookmarking, exposes the URL in plain. There are also much better ways of accomplishing this task.

There is no good reason to ever expose or transmit your database users password hash over a public network, and as part of normal operations, encrypted or not.

[HirschSt]

To my knowlage transmitting the auth_token with url is standard in SRU. If we really want to have it secure we must use 2FA.

[ahankinson]

That's OK -- transmitting an auth token is pretty normal.

What isn't normal is using the MySQL User's password hash as the token value, as suggested.

1. It exposes the hash over public networks. Yes, maybe it's encrypted, but it's still a bad idea;
2. It ties the auth token to their login password, so you can't expire the token without changing the password;
3. There are standard methods of doing token auth, so there's no need for us to invent our own.

2FA is a completely different conversation.