Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remember me #11

Open
molenzwiebel opened this issue Nov 10, 2016 · 1 comment
Open

Remember me #11

molenzwiebel opened this issue Nov 10, 2016 · 1 comment

Comments

@molenzwiebel
Copy link
Member

Something alike to Google's old account picker:
chrome-beta-37-account-picker

Would allow for easier logins, but needs a reliable/secure way to store data on the computer.

@clavin
Copy link

clavin commented Nov 20, 2016

Somebody asked after this issue was created, but I saw it before this, so I had some thoughts about this. In the end, I've come to the conclusion that a remember me/auto-login feature would be a bad idea to make.

Side note: I haven't written anything yet but I already know this'll be fairlylong. Be prepared.

Storing the Credentials on the User's Machine

First and foremost, storing the user's credentials in plaintext is very obviously a horrible idea. We can't store the credentials anywhere safe from everybody else, so therefore wherever we would store the credentials would be unsafe as anybody else (malicious applications attacking this flaw) would be able to get the credentials with no sweat.

So the next logical choice would be to encrypt the credentials. This is a great idea, however there isn't a good choice for the encryption (and decryption) key. Anything we choose as a key is accessible to be found by anybody else. We can't ask the user for a key as that would defeat the purpose of automatic login in the first place.

So How Do Other Services Offer Automatic Login?

They have the user store some kind of key or token that is used in place of the user's credentials. Usually, if the token is to be secure, the token is also recorded with some kind of unique information like a user's IP to prevent token theft/hijacking from being particularly useful.

There's two reasons a token is used:

  1. Tying a user's account to an IP address is a bad idea because a user's IP can change--often even.
  2. If an attacker steals the token then the common security issue of password reuse isn't very problematic at all; the attacker only has a token, not credentials, so they can't try to to attack other accounts a user has.

Storing the Credentials Ourselves for the User

This would be a lovely idea in a perfect world, however I don't think this is a good idea.

First and foremost, morals. I (personally) don't feel like storing other people's credentials for another service is a very warming idea. Similarly, I don't think users would be particularly welcoming to the idea either (but what do I know?).

If, however, you pass by the moral implications, you also end up with some other complications; for example, how do we prevent attackers (or even regular use by a large amount of users) from overloading storage?

Defending against attackers is a very hard task. My intuition says that the best defense would be to only store tokens that actually resolve to a proper authentication (better put, only store credentials if they're actual credentials that log into an account). This becomes tricky, however, because riot limits authentications based on IP. That means just checking alone could be problematic.

We could use proxies, however those proxies could end up getting used up by either an attacker's numerous proxies forcing us to attempt tons of credentials, or by usage of the service by a large amount of users.

Adding onto the issue of attempting to authenticate, doing so also technically pulls Riot's morals into question as, in the case where Riot disapproves of such behavior of automatic logins, they could also deny us access to authentication.

Alternatively, being able to store every users credentials could take up a lot of storage, and may even be costly (and I'd hate to see this project forcibly cost money). While we're on the topic of money, running a server to do all of this for us would probably also cost money.

Past those concerns, the question of how we'd get the user logged in is also very important. One option is to send the credentials (somehow encrypted, either manually or through HTTPS or both). This option raises the same issues that storage of credentials raises, just applied to transportation.

Another option is to log in for the user and just send back some kind of session. Similarly, this raises the same issues pointed out earlier about authenticating.

In the end, this approach technically somewhat works, but is very slow and _very_ hard to implement--especially without error.


If this is ever implemented, don't forget to implement it in a way so when the user doesn't want their data saved (e.g. unchecks a previously-checked "Remember Me" option) the old data is destroyed.

If we were riot then there wouldn't be many of the issues we faced. Hence, this shouldn't be a concern we deal with and, instead, something users should ask Riot about. Personally, I'd love to have a conversation with a Riot Security Engineer about this, but--honestly--I think it's all useless. Just type in your password.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants