EEAuth - EE login for every website.

Processor · Before February 2015

EEAuth
You can use your Facebook account to login on many other websites. Why not use your Everybody Edits account instead?
That is the idea behind EEAuth.

Explanation
Lets say, a site like http://eeforumify.com/ wants to allow people to login using their EE account.
Using EEAuth, eeforumify can add a new button on their page that would redirect you to https://eeauth.yonom.org/ where you will prove that you own an EE account.
EEAuth doesn't need you to input your password, instead, it asks you to join a random hidden world. EEAuth then joins this room itself and makes note of your username. This way, it can confirm your account ownership and at the same time protect your privacy.
It even works with any account type (ee.com/facebook/kong/armor etc.)
Once EEAuth is sure that you are the person you say you are, it redirects you back to http://eeforumify.com/ and tells eeforumify about your identity.
Forumify can now log you into the account associated with your username, while being confident that you aren't a hacker. (as long as your EE account is secure)

Possible usages
There are many fan sites that could make use of EEAuth. Imagine being able to login on EE forums using the same account that you use in EE. No more complicated registration forms!
There are many security benefits to this. Since many people use the same password they have on EE on third party sites, it will be very easy for your account to be hacked, if one of these other sites turns evil. EEAuth never asks for your password, it will never know your email either.

Demo
This has just been released, so there aren't any real websites using EEAuth. However, I have set up a demo website at https://testauth.yonom.org/ where you can see how EEAuth works in action.

Websites using EEAuth
-- None yet --
Meanwhile, I welcome any programmer to look at the https://eeauth.yonom.org/ API and I am very excited to see what people will create with EEAuth!

Credits
Credits for the idea goes to atilla, who had made a prototype that had the same concept as this one.
Special thanks to Hexagon and Meredith for suggestions.

Source Code
Source code of this project can be found here:
https://github.com/Yonom/EEAuth/tree/master/src

Last edited by Processor (Jan 4 2015 5:05:07 pm)

Xfrogman43

Anch · Before February 2015

Woah that's really cool. I don't understand any of this but I tried it and it works! Awesome!

Xfrogman43

XxAtillaxX · Before February 2015

It's a good idea but it's not implemented the best way.

You use a shoddy hosting site that can't be trusted. You use a bot that generates a room that isn't very unique and it can be seen on the room list with another bot.

You could offset this by changing the boolean to false, but it's still possible for a Guardian to tamper with possibly.
This is why it's best to authenticate directly with PlayerIO, you don't open up the possibility of an attack from an inside source like, say, 12 year old upset Guardians.

Furthermore, you don't have XSRF protections which would be an issue possibly in the future opening up an attack vector if someone embedded an iframe on Everybody Edits with an autojoin room Javascript variable set to the generated room ID that they could have gotten themselves.

This is why it's a good idea to create the key with a unique identifier that is not based off of IPs (easy to get from target) but instead a cryptorandom generated key, and not have it visible on the list of rooms.

My authentication was based off of PlayerIO itself which already creates (temporary, and possible permanent) keys when you log in.
This requires proper credentials, but with open source software you could easily make it trustworthy enough and more efficient for it's purpose.
Plus, it opens up a bunch more possibilities with account access that this wouldn't possibly be feasible to do.

Xfrogman43

Hexagon · Before February 2015

This post has just been based off Atilla's comments (and I haven't really looked at the source code).

I'm not sure if this would work, but what if:

1. Your website asks the user to input their EE username, and then, after clicking okay, creates a random room.
2. The user joins that room. The website then asks the user to type in a code in the chat box.
3. If the user (with the correct username) types in that code (as it'll ignore codes from everyone else; anyone can join the room and pass the code around, it doesn't matter) then it can be safe to say that the user owns that account.

Last edited by Hexagon (Jan 4 2015 1:08:37 pm)

Xfrogman43

XxAtillaxX · Before February 2015

Hexagon wrote:

This post has just been based off Atilla's comments (and I haven't really looked at the source code).
I'm not sure if this would work, but what if:
1. Your website asks the user to input their EE username, and then, after clicking okay, creates a random room.
2. The user joins that room. The website then asks the user to type in a code in the chat box.
3. If the user (with the correct username) types in that code (as it'll ignore codes from everyone else; anyone can join the room and pass the code around, it doesn't matter) then it can be safe to say that the user owns that account.

I suggested that to him earlier.

Inherently, it's flawed because it relies on an in-game bot to function.
It isn't authenticating directly with PlayerIO which is a massive security issue. (I'm sure most people would overlook it though, sadly.)

Xfrogman43

Processor · Before February 2015

XxAtillaxX wrote:

It's a good idea but it's not implemented the best way.
You use a shoddy hosting site that can't be trusted.

Agreed.

XxAtillaxX wrote:

You use a bot that generates a room that isn't very unique and it can be seen on the room list with another bot.

XxAtillaxX wrote:

This is why it's a good idea to create the key with a unique identifier that is not based off of IPs (easy to get from target) but instead a cryptorandom generated key, and not have it visible on the list of rooms.

The IDs are (crypto-)random and not based on your ip in any way.

XxAtillaxX wrote:

You could offset this by changing the boolean to false, but it's still possible for a Guardian to tamper with possibly.

I can't. I already do set the "magical" boolean to false. Yet, the servers change it back to true, however I try to talk with MrShoe about this and see if it can be resolved in any way.

XxAtillaxX wrote:

This is why it's best to authenticate directly with PlayerIO, you don't open up the possibility of an attack from an inside source like, say, 12 year old upset Guardians.

A such "attack" on EEAuth would not cause any security breaches. If a guardian decides to, they can tamper and make you login as themselves instead of yourself, this would only cause annoyances. This is something inevitable, ISPs can block SSL traffic which is essentially the same thing.

XxAtillaxX wrote:

Furthermore, you don't have XSRF protections which would be an issue possibly in the future opening up an attack vector if someone embedded an iframe on Everybody Edits with an autojoin room Javascript variable set to the generated room ID that they could have gotten themselves.

Pure speculation. I do have CRSF protection on both sides. (EEAuth website and the room)

XxAtillaxX wrote:

My authentication was based off of PlayerIO itself which already creates (temporary, and possible permanent) keys when you log in.
This requires proper credentials, but with open source software you could easily make it trustworthy enough and more efficient for it's purpose.
Plus, it opens up a bunch more possibilities with account access that this wouldn't possibly be feasible to do.

That would require you to trust the website you are on, not everyone can code. I'm not sure one is allowed to use the PlayerIO apart from their official APIs, so this might even violate some licences.

Xfrogman43

XxAtillaxX · Before February 2015

Processor wrote:

too long to quote

>The IDs are (crypto-)random and not based on your ip in any way.
The IDs generated by PlayerIO and by looking at your bot, aren't cryptographically random.

>A such "attack" on EEAuth would not cause any security breaches. If a guardian decides to, they can tamper and make you login as themselves instead of yourself, this would only cause annoyances. This is something inevitable, ISPs can block SSL traffic which is essentially the same thing.

It would cause security breaches and by providing your own example you contradict yourself.
There isn't a perfect system for this and there likely never will be, but like cryptography in itself, it's not about making it impossible, it's about making it impractical.
Right now, the system isn't compromised and that's a benefit.

>ISPs can block SSL traffic however when they do that, it's very noticeable and it does not change anything to those wishing to protect their security and privacy. I digress, but this is a digression in of itself.

>That would require you to trust the website you are on, not everyone can code. I'm not sure one is allowed to use the PlayerIO apart from their official APIs, so this might even violate some licences.

Not everyone can code but that doesn't mean set the standards lower.
In the terms of service it says nowhere that you cannot create/use the APIs outside of their libraries. Plus, the United States (where PlayerIO is hosted at) has ruled that APIs cannot be copyrighted. This was fairly recent law passed.

It makes more sense to just use a normal login system like any other site. Convenience is certainly on your side but nowadays it isn't hard to create an account with emails (which I'll add, isn't the most secure either).

Xfrogman43

Processor · Before February 2015

The IDs generated by PlayerIO and by looking at your bot, aren't cryptographically random.

They are. They might not be cryptographically secure as much as you think they should be, but they are random, I can assure you that.
Logins timeout in 10 minutes, it is close to impossible to generate a valid ID in this amount of time. (PlayerIO requests take significant time to process)
The number of valid combinations is around 62^11.

It would cause security breaches and by providing your own example you contradict yourself.
There isn't a perfect system for this and there likely never will be, but like cryptography in itself, it's not about making it impossible, it's about making it impractical.
Right now, the system isn't compromised and that's a benefit.

If this becomes an issue (preventing people from using the service) it doesn't take much time to patch the system to properly ignore the hackers.

ISPs can block SSL traffic however when they do that, it's very noticeable and it does not change anything to those wishing to protect their security and privacy.

Same thing here, it is very noticeable if another user intercepts in your login session. It does not cause any breaches to your privacy or security either. (Do you have an example how my security would be compromised?)

It is easy to do some attack like this as of now, but as I've said, I'm working on securing this system.

Not everyone can code but that doesn't mean set the standards lower.

You can argue that this implementation isn't the best possible, however, asking people for their passwords on a third party site has a far lower standard on security than this method.

In the terms of service it says nowhere that you cannot create/use the APIs outside of their libraries. Plus, the United States (where PlayerIO is hosted at) has ruled that APIs cannot be copyrighted. This was fairly recent law passed.
It makes more sense to just use a normal login system like any other site. Convenience is certainly on your side but nowadays it isn't hard to create an account with emails (which I'll add, isn't the most secure either).

Maybe, until the world visibility issue is fixed. But if you want to make sure some user owns a particular username in EE, you might want to use something like this.

Last edited by Processor (Jan 5 2015 3:57:06 am)

Xfrogman43

Processor · Before February 2015

Since atilla has been making up a lot of wrong assumptions about the security of EEAuth, I've decided to open source the code so everyone can see what is going on behind the scenes.

The source code (of both the website and the C# application) can now be found at
https://github.com/Yonom/EEAuth/tree/master/src

Xfrogman43

XxAtillaxX · Before February 2015

Processor wrote:

Since atilla has been making up a lot of wrong assumptions about the security of EEAuth, I've decided to open source the code so everyone can see what is going on behind the scenes.
The source code (of both the website and the C# application) can now be found at
https://github.com/Yonom/EEAuth/tree/master/src

Should have been done at the start. No need to get defensive, either.

Xfrogman43

Cyclone or Meredith · Before February 2015

Pew pew pew.

On another note, why not generate a room ID and give a specific phrase to say. If you deliver the phrase on the site and have the user say it in the game and verify its the correct user saying the phrase there's no possible way to tamper. This all relys on the EE account being secure and since this is an assumption that is a prerequisite to an EE auth I do not see a better way.

Xfrogman43

Processor · Before February 2015

Update:

I've implemented the method suggested by meredith. Thanks to both Hexagon and meredith for this idea!
This should fix the tampering issue mentioned by atilla and others.

Xfrogman43

hummerz5 · Before February 2015

Don't anyone mistake me to be a super-crypto-knowhow-person.
As a user:
I get the feeling that the codes are making it secure. This XSRF has me wonderin' but, as far as EE/PlayerIO is concerned, I can't see anyone joining within the 10 minutes and cracking the code... so it'd have to be something out of my knowledge.

Secure? Seems like it. Practical? I dunno

Xfrogman43

Buzzerbee · Before February 2015

Cool idea. Maybe for nonchats you can have a series of quickchat messages that verifies them.

e.g.

"Press alt+2, then alt+5, then alt+4, then alt+4, then alt+1"
or "Say "Goodbye.", then "Follow me.", then "Thank you.", then "Thank you.", then "Hi.""

Last edited by BuzzerBee (Jan 5 2015 9:45:51 am)

Xfrogman43

Koya · Before February 2015

Now to build a website which actually uses this...

Xfrogman43

Hexagon · Before February 2015

Metatron wrote:

Now to build a website which actually uses this...

Speaking of website, how stable is this processor? I'm possibly thinking about using it in a website.

Xfrogman43

Processor · Before February 2015

Hexagon wrote:

Metatron wrote:
Now to build a website which actually uses this...
Speaking of website, how stable is this processor? I'm possibly thinking about using it in a website.

The server should be able to handle some hundred people trying to login at the same time. It seems to be pretty stable so far. It is a free service and there are no guarantees about the uptime, but I will do my best to keep the site up as much as possible. You shouldn't worry either way, because anyone can host this since it is open source.

I'm very excited to see what people make with this!

Last edited by Processor (Jan 8 2015 12:30:06 pm)

Xfrogman43

Buzzerbee · Before February 2015

I have a really good idea for this but not nearly enough time to make it

Xfrogman43

Hexagon · Before February 2015

Regarding creating open rooms, you can create somewhat private stateless ephemeral rooms by joining a room whose id is of a pattern such as "PW" + (6 alpha-numeric characters) + "I". The room shows up as "Untitled World" at the end of the lobby (not in the open worlds tab) and the plays, woots doesn't save (as it belongs to nobody).

It's still possible for someone else join this type of world, but it's a smaller target as it has no value (nobody can edit it, it's just really bland) and permanently disappears once everyone leaves.

Xfrogman43

Anch · Before February 2015

Maybe this can be implemented into this forum!

Xfrogman43

Zumza · Before February 2015

Nononno! Please don't!

Xfrogman43

Processor · Before February 2015

Hexagon wrote:

Regarding creating open rooms, you can create somewhat private stateless ephemeral rooms by joining a room whose id is of a pattern such as "PW" + (6 alpha-numeric characters) + "I". The room shows up as "Untitled World" at the end of the lobby (not in the open worlds tab) and the plays, woots doesn't save (as it belongs to nobody).
It's still possible for someone else join this type of world, but it's a smaller target as it has no value (nobody can edit it, it's just really bland) and permanently disappears once everyone leaves.

Thanks a lot for the suggestion! It turns out that this even works with rooms with longer ids (7 or 8 characters). This is a very awesome idea, I will look into implementing it.

UPDATE: Actually, I've decided not to implement this. Since currently, a room with 2 players isn't displayed very far down in the lobby, there is a high chance that random people will join. In fact, that's what happened while I was testing. Thanks anyway.

Last edited by Processor (Jan 10 2015 9:55:22 am)

Xfrogman43

Anch · Before February 2015

Mhhhh maybe the account Authbot (I think it was called) can have like a really large amount of worlds then it can make it visible true and visible false so only you can enter it.
Like once you enter the world it turns visible false then when you put in the code, it makes it visible true then it kicks you.

Xfrogman43

Hexagon · Before February 2015

anch159 wrote:

Mhhhh maybe the account Authbot (I think it was called) can have like a really large amount of worlds then it can make it visible true and visible false so only you can enter it.
Like once you enter the world it turns visible false then when you put in the code, it makes it visible true then it kicks you.

That's an interesting idea. Building upon this, if there was one special authbot room, with a bot running (24/7) that kicks everyone except the user who needs to authenticate (and of course authbot), that might work too. However, having a bot running all the time just to kick users is a bit wasteful.

Xfrogman43

Processor · Before February 2015

Hexagon wrote:

anch159 wrote:
Mhhhh maybe the account Authbot (I think it was called) can have like a really large amount of worlds then it can make it visible true and visible false so only you can enter it.
Like once you enter the world it turns visible false then when you put in the code, it makes it visible true then it kicks you.
That's an interesting idea. Building upon this, if there was one special authbot room, with a bot running (24/7) that kicks everyone except the user who needs to authenticate (and of course authbot), that might work too. However, having a bot running all the time just to kick users is a bit wasteful.

The current implementation can support 500 users authenticating at the same time. I'd rather not introduce a limit to this.

I had another idea, that there would be a special authroom, where the bot would kick you with a number that you have to enter to login. In fact, this was my initial implementation. The problem with this method is that people might be able to see the kick messages of others by joining over and over multiple times. The 5 minute kick period is annoying as well.

Anyway, why are we looking into alternative methods? Is the current one broken?

Last edited by Processor (Jan 10 2015 1:18:40 pm)

Xfrogman43

Official Everybody Edits Forums

#1 Before February 2015

EEAuth - EE login for every website.

#2 Before February 2015

Re: EEAuth - EE login for every website.

#3 Before February 2015

Re: EEAuth - EE login for every website.

#4 Before February 2015

Re: EEAuth - EE login for every website.

#5 Before February 2015

Re: EEAuth - EE login for every website.

#6 Before February 2015

Re: EEAuth - EE login for every website.

#7 Before February 2015

Re: EEAuth - EE login for every website.

#8 Before February 2015

Re: EEAuth - EE login for every website.

#9 Before February 2015

Re: EEAuth - EE login for every website.

#10 Before February 2015

Re: EEAuth - EE login for every website.

#11 Before February 2015

Re: EEAuth - EE login for every website.

#12 Before February 2015

Re: EEAuth - EE login for every website.

#13 Before February 2015

Re: EEAuth - EE login for every website.

#14 Before February 2015

Re: EEAuth - EE login for every website.

#15 Before February 2015

Re: EEAuth - EE login for every website.

#16 Before February 2015

Re: EEAuth - EE login for every website.

#17 Before February 2015

Re: EEAuth - EE login for every website.

#18 Before February 2015

Re: EEAuth - EE login for every website.

#19 Before February 2015

Re: EEAuth - EE login for every website.

#20 Before February 2015

Re: EEAuth - EE login for every website.

#21 Before February 2015

Re: EEAuth - EE login for every website.

#22 Before February 2015

Re: EEAuth - EE login for every website.

#23 Before February 2015

Re: EEAuth - EE login for every website.

#24 Before February 2015

Re: EEAuth - EE login for every website.

#25 Before February 2015

Re: EEAuth - EE login for every website.

Board footer