Hyrax: Hyrax::UsersController#index viewable by public

[revgum]

Descriptive summary

The index listing for users of the system is viewable by unauthenticated/public viewers, see https://nurax.curationexperts.com/users

At Oregon State University, we're going to restrict this view to repository administrators only and think this work should probably happen upstream as well.

[jcoyne]

Why do you want to restrict it? Don't the users display in the search results anyway? It is possible that this change would adversely impact harvesting by search engines.

[vantuyls]

per conversation on slack - recommendation is to:

• add a flipper for public vs. authenticated user index; default authenticated
• add config for role authentication; default :admin

@no-reply

[vantuyls]

@jcoyne it's a bit of a security issue. i think if that info is useful for search indexing purposes we need to find a way to mitigate the (potential) security problem.

[jcoyne]

@vantuyls In what way is it a security issue?

[jcoyne]

I'd also like to note that it's trivially easy to construct a user index by iterating over all possible usernames ( 6-10 letters) and hitting:
https://ir.library.oregonstate.edu/users/{username}

[vantuyls]

so, the security issue that was brought up is that by providing a complete list of user keys, we are giving bad actors a head start on brute forcing logins. I understand that one can construct the user index using the method you described, but i'd rather make it less easy. @no-reply thoughts?

[jcoyne]

How does having a complete user list benefit an attacker when they only would need a single account name to do a brute force attack? Since your account names correlate with your email adddresses which are public and strongly with the people who have content in the system (also public) you aren’t doing anything useful wrt securing the system. You are making it more difficult for benign actors to be exposed to the data.

[no-reply]

Since your account names correlate with your email adddresses which are public and strongly with the people who have content in the system (also public) you aren’t doing anything useful wrt securing the system.

I'm not sure this set of assumptions holds at all. The user keys exposed here are frequently otherwise private SSO ids, right?

I'd also like to note that it's trivially easy to construct a user index by iterating over all possible usernames ( 6-10 letters) and hitting:
https://ir.library.oregonstate.edu/users/{username}

At least one existing DCE-developed application significantly reduces the amount of information on the /users/{id} view, for exactly this reason.

I don't think the assumption that personally identifying information about users of the system is public is one we can afford to make on behalf of all adopters.

[jcoyne]

@no-reply I'm perfectly happy with saying we don't want to expose personal information. I am at odds with saying that IT security is the reason.

[no-reply]

@no-reply I'm perfectly happy with saying we don't want to expose personal information. I am at odds with saying that IT security is the reason.

I don't understand the distinction (leaking personal information seems like an IT security issue to me), but we seem to be in agreement apart from semantics; so, onward!

[no-reply]

It turns out this is a duplicate of #438.

@vantuyls do you have a preference about which ticket we keep?

[vantuyls]

lets keep this and close #438. This issue gets into a little more detail.