Runelite: Use Token instead of Username/Email address

Created on 1 Mar 2019  路  6Comments  路  Source: runelite/runelite

There are some privacy issues regarding stored usernames and email addresses. Right now the login username or email address is used to link your account with RuneLite. This should be changed to an anonymized account token.

There are many privacy and security issues regarding this. The most obvious one is that the usernames and email addresses can be cross-referenced with password breaches of other websites. People often use the same password and this information is valuable as it gives attackers a list of people who are known to have an active runescape account. Even if people put their password in their notes, without an identifier to use, the accounts would be much safer.

Hence why I suggest the following migration, (username means login username or email address):

  1. One way hash serverside usernames into a token and store it alongside the username
  2. Refactor ALL hardcoded config keys that use the username to not use it or use the token. Examples are: timetracking..... and killcount..wintertodt. (I only play a low level ironman and do not have much more config values that use the username in my settings.properties file, but find-all shows 25 matches for getUsername() in the plugin package).
  3. Add a client-side migration to convert all old config values containing the username to ones that use a token, or add a legacy check that converts the token during config lookups with the username if it wasn't found with the token
  4. Move the "loginscreen.username" configuration value to the local computer, or explicitely ask the user if they want to sync it. This could be done with a token-map so different RuneLite accounts can load different local usernames.
  5. Start saving the display name so it can be used to show to the user on the website
  6. Push the update so players start using the token
  7. Remove the usernames that are being accessed from their token
  8. After a period of x amount of days we can remove all left-over usernames

That way the username is removed both as an identifier and as a string in config variables, in 1 update with backwards-compatibility. And to support older clients, the username and config key could be converted during the requestat the server-side, as that only happens in memory.

For generating the token I suggest a slow algorithm as it only has to be done once in a while. And the time of hashing on the server could only be an issue during migration.

There was also some talk about configuration scopes and profiles, but that doesn't change the fact that usernames are visible to the RuneLite devs. This is also meant as a fast privacy/security fix and not a whole new way of storing configuration.

discussion

Most helpful comment

I completely disagree. There are no security or privacy issues with this. The server stores usernames, which can include email addresses, in a secure way which are not ever given to any other users. No part of RuneLite stores passwords.

WIth that being said, I am okay with changing it to not store usernames. I am not willing to guise it under some "security" fix or try to band-aid fix the problem from trying to rush it though.

As I have already stated, the reason why the config requires the usernames in the keys is for account-specific configuration items. I would like to make account-specific config items a first class citizen of the config system, by the use of config profiles. If we did this, we could very easily change the way accounts are identified to be based on a hash rather than the username. Changing the existing key-value based system to store some username derived hash would just make the current situation worse than it already is and make fixing it more difficult.

All 6 comments

Related: runelite/runelite.net#215

If your email address being not private is a security issue for you, you have much deeper and more pressing issues than us.

I completely disagree. There are no security or privacy issues with this. The server stores usernames, which can include email addresses, in a secure way which are not ever given to any other users. No part of RuneLite stores passwords.

WIth that being said, I am okay with changing it to not store usernames. I am not willing to guise it under some "security" fix or try to band-aid fix the problem from trying to rush it though.

As I have already stated, the reason why the config requires the usernames in the keys is for account-specific configuration items. I would like to make account-specific config items a first class citizen of the config system, by the use of config profiles. If we did this, we could very easily change the way accounts are identified to be based on a hash rather than the username. Changing the existing key-value based system to store some username derived hash would just make the current situation worse than it already is and make fixing it more difficult.

I'm very much in favor of changing the configuration as you mentioned in Discord. The part about changing configuration keys that contain the username would just be a temporary fix, so that they wouldn't be stored on the server anymore while you work on removing them altogether.

An email address is personal data, and should be treated as such. When the database leaks, significantly less personal information is leaked when using a token (for example a token provided by OAuth services like Google). I'm not sure if RuneLite has to comply with GDPR, but implementing tokens instead of emails would reduce the damage done in case of the database leaking.

I actually work with GDPR compliance. Any database that includes any person(s) who have residency or citizenship in a country associated with the EEA has to comply with the GDPR. If we're storing data subjects personal information (IP addresses, account names, emails,) then there are several steps that have to be taken in order to secure that data and keep track of it. If ANYONE can look at a piece of data and say "I know who that belongs to," then it counts as personal data. Tokens would be a wonderful solution to this, so long as the token isn't associated with the email address in order to make the data "truly" anonymous.

Was this page helpful?
0 / 5 - 0 ratings