OC Admins can't change cache password

[deg-pl]

OC Admins can't change password for caches owned by other users

[rapotek]

The simplest solution looks like an easy one: add || $loggedUser->hasOcTeamRole() to the if condition in editcache.php, line 282.

BUT: There is a comment above // don't display log password for admins.
BUT 2: The already used solution preventing viewing password by admins is so weak (simple HTML comment), that it is enough to look into generated page code returned from server to know the log password.

So, my question is: should it really be fixed in this way or should there be f.ex. a separate switch/button/page for changing password by admins to prevent viewing it accidentally while doing some another editions?

And another question: should log passwords be stored in plaintext as it is done now or should they be hashed?
Advantages of a plaintext: the cache owner can easily verify if a text entered as a password is correct.
Advantages of a hash: no one can see the stored password by accident, because they can only see the password hash. Storing passwords in a hashed way is a widely recommended solution.

[kojoty]

My 5 cents: I think there is no sense to hide password in DB - very limited number of people have access to production data and i think this is not a problem (especially i have such access ;)) What we need in my opinion is just a button for oc team to reset password Regards Kojoty

…

On Monday, May 31, 2021, rapotek ***@***.***> wrote: The simplest solution looks like an easy one: add || $loggedUser->hasOcTeamRole() to the if condition in editcache.php, line 282. BUT: There is a comment above // don't display log password for admins. BUT 2: The already used solution preventing viewing password by admins is so weak (simple HTML comment), that it is enough to look into generated page code returned from server to know the log password. So, my question is: should it really be fixed in this way or should there be f.ex. a separate switch/button/page for changing password by admins to prevent viewing it accidentally while doing some another editions? And another question: should log passwords be stored in plaintext as it is done now or should they be hashed? Advantages of a plaintext: the cache owner can easily verify if a text entered as a password is correct. Advantages of a hash: no one can see the stored password by accident, because they can only see the password hash. Storing passwords in a hashed way is a widely recommended solution. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2288 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAWTAKFGNZ33EUIOV5OXU7LTQMXBPANCNFSM45ZH52JA> .

[jrmajor]

And another question: should log passwords be stored in plaintext as it is done now or should they be hashed?
Advantages of a plaintext: the cache owner can easily verify if a text entered as a password is correct.
Advantages of a hash: no one can see the stored password by accident, because they can only see the password hash. Storing passwords in a hashed way is a widely recommended solution.

@rapotek Storing passwords as hashes is the recommended solution when they're used for authentication. Cache passwords aren't even secret — they're supposed to be known to every person who found the cache.

I agree with @kojoty that enabling OC team to reset cache passwords is enough.

[andrixnet]

@rapotek:
For the purpose user authentication passwords MUST be stored in hashed form.
Cache passwords don't impact anything related to user privacy. Furthermore, they gradually become known to each geocacher that found the cache. And it's no secret that some may share this information between them (just as some final coords).

Furthermore, having the password available to the cache owner in plaintext form is a usability thing that benefits the cache owner.

@kojoty: what exactly do you mean by "OC Team" resetting such a password?

• log password is visible to cache owner

• should log password be actually visible to OC-Team?

• log password will be visible to server admin (has DB access)

• if OC-Team is allowed to edit password, then this would mean entering any string

• if OC-Team is allowed to "reset password", then this would mean removing the password entirely? (leaving the cache without password and loggable by anyone)

• if OC-Team resets password and a new password is generated, and this is notified to the cache owner (following the same procedure as user auth password reset), then this will render the cache NON-LOGABLE until the cache owner either changes the password himself (likely back to the old value), or does physical cache maintenance to place the new password in the physical cache.

• if the log password is based on something actually found in the field, then the cache owner does not have physical control over the actual password, thus forcing such a change/reset complicates things.

According to the rules (as they are now), what would be the reasons for OC-Team interveaning like this? (acting on log password)

• abuse of existing password? (is it the owner's fault?)
• the actual password being reported to be a problematic text string (idk, obscene/rasist/etc?)
• other ?

Also, if it isn't already, IMO OC-Team intervention powers on log password should be mentioned in the rulebook.