Login-based vs key-based authentication

[emoose]

So we should finally discuss this properly, in the public eye instead of behind closed doors. Most people probably know I'm against a login-based system, while I know most others are for it. I think we should come to a decision before people spend time on things that might not be used (eg the entire stats portion..)

The way I see it, a login-based system provides authentication (proving a user is who they say they are) along with authorization (being able to check if the user has special access to certain permissions/things). A key-based system would only allow us authentication, which IMO is all we really need.

I know some people are wishing for a "dew ID" kind of system where you can claim your ingame name and nobody else can use it, along with permitting special things for this ID (such as special armor effects for devs etc), I'm not really for that -- I do this work because I enjoy doing it, not because I want to be rewarded in any way. For ingame names I always wanted a system sort of like steams, where players are identified by some other unique attribute other than their name, so their ingame name could be anything they want even if it's already taken.

The beauty of ED right now is that someone can easily take our code, edit a single int and they'd have their own fork of ED running fine separate from our main ED. In seconds they could spin up a master server with Docker and even have a server list for their game up and running.

If we were to make it use a login-based system I can see the server setup being a lot more complicated, you'd have to make sure that your server is secure and there's no way for anyone to steal the user database, and I doubt many people would be able to make their servers reasonably secure enough.

The main issue I see with a login based system is that no matter what we'll need a central server to store the user database, maybe this could be supplemented with other servers sharing the same data etc, but then that brings the risk of the data being stolen up by quite a lot.

I don't see why we should have to worry about keeping data secure when we don't even need that data in the first place, like said above we only really need to authenticate the user, and with a crypto based system we can do that easily without needing to store any data ourselves. Master servers put up by the community wouldn't need us to share any secret key with them or anything, they'll be able to work as a single unit without needing any connection to us.

The only real issue I can see with a crypto based system is key loss, and that could easily be solved by allowing master servers to store the users private key (encrypted with a password) tied with their email address. This way masters won't be storing any sort of password hash, only an encrypted version of the players private key. If the user loses their key they can request the master to send it to them, and the master could send that encrypted key blob to the users email (which makes sure the only recipient is the actual owner of the key), the user would copy this blob as "keyrecovery.txt" into the ED folder, and then ED would ask them for the password for the key (ensuring the key is decrypted by the client, instead of having the password sent to the server for decryption).

I'd be fine with this way, it's a lot like a login-based system except there's no passwords or password hashes stored, and all the masters could hold these encrypted private keys instead of needing to rely on a central server. With reasonable enough encryption it would make bruteforcing/decrypting these encrypted keys very hard and CPU heavy compared to simply cracking a password hash, meaning if a dump of these encrypted keys got out they'd have a much lower chance of being cracked versus a dump of password hashes.

Anyway I don't want to push my views on people, this is a community based project so I'd like to hear peoples thoughts on this.

[kiwidoggie]

Glad this has finally been brought out. I believe a hybrid between the two should be best. You are able to connect to any instance of the backend, and play temporarily (or even forever as long as you back up your crypt token). I think the login based isn't that hard to implement properly, and should have some kind of system to plug in any kind of authentication system.

I currently have been working on a system for dewrito as a proof of concept. This gives us the best of both worlds, if people want to register their tag/be able to recover their account, they should be forced to sign up for everyone's sanity's sake. (Dev's and client's alike) But with that being said it should NOT be a requirement to at least join a game and fun around. Things like name reservation etc can be done once we have a tracking system of players.

This will allow people to do a few things, they can start their own communities with whatever auth system they want, also it allows services like stats and such to keep down on server load/use because you will have to do 1 easy step in order to save stuff instead of it being a public upload service which can get abused/waste of bandwidth.

Edit1: Also, theft of information is not an issue when implemented correctly. If we proceed with some idea's from you and myself, as well as any from the other community we can have cross-auth/player information without actually leaking any personal user information (emails, names, etc). In the case where any node can use any authentication system, it will be up to the owner of the database to keep it secure. This would allow people to just join with a identifier get it verified by any auth system and gain access to xyz resources. Where xyz resources is Stats, FileShares, Presence, etc.

With this way, even if your internal id got leaked, who care's it wouldn't be privileged without a proper internal token. Also it gives user's more freedom to signin with for example, Steam, Facebook, Twitter, Halo.Click, Nexus, etc.

Edit2: I wrote my proof of concept in Node.js and C++. (C++ Client side, Node Server) but it can be easily ported to any language.

[emoose]

I'd really prefer a loginless system though, I don't see us using anything that requires logins to work, so why not use a loginless system? Users will be able to use the full features of ED without any setup required, and there would be no single person controlling the login database: like I said before anyone could setup a master which can handle authentication, and they wouldn't need to do any lookups against a central database.

This way doesn't need us to setup and maintain a login server neither, so in the long run it's less work for us, and also more secure as hackers will have a harder time trying to defeat RSA4096 crypto than they would a homebrew login server.

It's more stable too. If we used a central login server the whole system would die if that server went down, but by using a loginless system there's no dependency on a central server, masters would only be used for mapping emails to keys for key recovery.

[Riven-Spell]

I'm for the key system, personally.

There is no reason at all to do logins.

[Red-M]

You could use OpenID in which you can use with steam to provide a way to login to ED (You login via steam and allow ED to use it to base your login off ( https://steamcommunity.com/dev ), this could provide a seamless way to not require a login database and means we hold no passwords, just SteamID to name). You could also approach this with allowing servers to run in an offline mode where no auth is done on the username with the OpenID system (similar to how minecraft servers work in their authentication, this removes the need for the master servers to the auth but they should be able to see some auth data incase we want to say remove someone's access to the lists), offline mode however would remove the secure lock from the server's listing on the master list (similar to TF2, CSGO and other valve games do their server lists).