Change the CSWeb password do not invalidate the client CSEntry credentials.

[lestcape]

One of the Android tablets that had a user's credentials saved was lost, and so we decided that to prevent it from being misused, we should invalidate the credentials saved on the tablet. We thought the way to do it was to simply change the password, but we were in for a surprise. Even after changing the password for this user, the credentials saved on another tablet used by this same user were still valid for CSWeb. So we could see that this would also happen with the tablet that was lost...

The only way we found to invalidate the credentials saved on the tablet was to change the username, but this obviously has many drawbacks. I think a simple password change should work to invalidate the credentials, and the fact that it doesn't work this way should be considered a security issue. This is why I am reporting it.

[Gregory Martin]

This is similar to some other services, where you can change your password without having to reenter it all on all devices. For example, as I recall, if I change my Gmail password, I don't have to reenter it on my Android device. CSWeb handles this by issuing refresh tokens. You can see them in the `oauth_refresh_tokens` table. This refresh token is stored on the tablet, so as long as it has not expired, the user can log in without providing the new password.

I don't really work with CSWeb, so I'm not sure how long these tokens last, but you can remove them manually:

Code: Select all

DELETE FROM `oauth_refresh_tokens` WHERE `user_id` = 'FILL THIS IN';

When the U.S. government shutdown ends, I'll show this to the active CSWeb developer. Perhaps we can add an option, once you change a password, to remove all the refresh tokens.

[lestcape]

Thanks. I think, as you suggest, automatically remove the refresh tokens, once you change a password is something good to have. In my opinion it is counterintuitive not to do so. I didn't know Gmail did that either... Ohh, how scared I am now of losing my phone or having it stolen, something very common in Mexico.

[lestcape]

I just tried, and unfortunately, deleting the refresh or access tokens from the server didn't solve the problem... So, I can't use anything like:

Code: Select all

DELETE FROM oauth_refresh_tokens WHERE LOWER(user_id) IN ('FILL THIS IN')

Code: Select all

DELETE FROM oauth_access_tokens WHERE LOWER(user_id) IN ('FILL THIS IN')

I assume the token is stored on the client, and on the server, the token is dynamically regenerated when needed to compare it with the one sent by the client... The oauth_refresh_tokens and oauth_access_tokens tables seem more like history than anything really useful for this.

I assume this happens because the access token is generated based only on the user and not the password, and therefore, when it is dynamically regenerated on the server based only on the user, it doesn't matter what you did with the password, since it is not included as a key in the hash.

Furthermore, if I am correct and the password is not included, someone who knows the algorithm and who knows the seed to use for hashing can generate a credential, knowing at least one valid username.

[Gregory Martin]

Interesting. I am surprised that this didn't work. When the U.S. government shutdown finally ends and the team reassembles, we will talk about how to improve this for CSPro/CSWeb 8.1.