Login-based vs key-based authentication about dewrecode

[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).