How to seamlessly verify a unique identity without requiring username/password?

[Deozaan]

OK so here's the situation:

I program games. Nothing fancy. Nothing popular. Nothing that anybody except my mom has played. (Thanks, mom!)

But I do occasionally have ideas for games that would work better with certain "community" features. A few examples:

• Cloud saves.
• A game with a level editor, where players can submit and download user created levels.
• A racing game where not only are best racing times recorded (leaderboards), but also "ghosts" which you can download and race against.
• Asynchronous turn-based games that will require some sort of account system to keep track of who is playing against who, and prevent players from playing games/turns they shouldn't have access to.
• Friends lists to make it easier to start a game with people you know.
• A game with automatic matchmaking based on an Elo-like rating system^w.

Naturally, I'd need some sort of database/account system to keep track of which data belonged to which player. But I really don't want to make the players of my games have to deal with creating yet another account, or deal with password resets or things like that. I just need to verify that the player is who they say they are, and then let them play. This should be a one time process, per device/profile. i.e., if they install my game on their Android device, they'll need to authenticate once, then the app itself will store the token locally and access their game data that way. But if they also install the game on their PC, they'll need to authenticate once on the PC, too. And if they make another profile on the PC (if I am smrat and make the game support multiple profiles) then the profile will need to be authenticated for the new person.

I don't want or need any personal information. If hackers get access to my database, I want it to only contain non-personal information. Only game related stuff like scores, ghosts, friends lists, games, etc. This way a security breach isn't really a problem. All the data will essentially be public anyway, so the only thing I'd need to be worried about is if the hackers decided to delete the data.

Yes, there are third-party solutions that offer leaderboards and the like, but in my experience both as a player and as a developer, they have 2-3 big problems:

1. They are unreliable, smaller companies which disappear after a year or two, thus breaking all game functionality that relied on them.
2. They are reliable, huge companies (Google, Steam, Apple) but are not cross-platform.
3. They are reliable companies, but charge more money than I'm willing to pay since it's just going to be my mom playing my games.

My thoughts were to use OpenID, but that was designed to be used in the web browser, redirecting to the provider's page, then back to the content. I can't exactly do that from within a game. So maybe I want to use OAuth? Even then, I'm not sure. This is because, again, I don't wan't access to any of their account information from the OAuth provider. I just want a way to verify they are a specific, unique person, then automatically access their game account details from there.

In other words, once they are logged in, the account information would be mostly behind the scenes. I'm thinking that all I'd need is a unique token that never changes (so they can login again after a reinstall or on another device) and that token will be the key/index to the rest of their account information in my database.

Am I going about this the right way? If so, how would I go about using an already existing service provider to provide me with a token which I could then tie to the player's account, without requiring the player to create a username/password to login with every time they launch my game? I think I could even use something like a time-limited code (like what we often see in 2-factor authentication) so that they only need to type in a relatively short numeric code and it will grab all their details automatically. But again, the question is how do I do this seamlessly from within the game, without requiring them to use a browser for authentication?

So what should I use? OpenID? OAuth? WebID? Persona? Something else entirely?

[mouser]

It seems like these days another common solution is to let people "log in" and identify themselves via their facebook/twitter/google id.

[Deozaan]

It seems like these days another common solution is to let people "log in" and identify themselves via their facebook/twitter/google id.

-mouser (January 06, 2014, 07:15 PM)

I think that's part of OAuth or OpenID.

[kamahl]

I think that's part of OAuth or OpenID.

-Deozaan (January 06, 2014, 07:24 PM)

You can do it with both.  OAuth would be much more useful for a non-browser app.

However, my solution would be this:

• Each device/profile gets a GUID on first run.
• Player is prompted to link profile to an email address.
• If they do, send a confirmation email, and add the GUID to a database: [Email address]<[GUIDs]
• Merge data from local profile to email address

The profile ID is a unique identifier. This essentially means you don't need a password, because having the device is enough proof.
Linking to an email address should be optional. Only required if a user wishes to merge to GUIDs into a single profile.
Other than a once off association (Which is optional), the user doesn't need to see the login process again.

[Shades]

Sounds like you want to use a certificate based setup. This is a lot of hassle for the one handing out certificates and these need to be of sufficient strength (read: quite costly in computing resources to generate) and it would be better if these certificates aren't valid for a long period of time.

Once setup the procedure for logging in is not that difficult anymore, but getting this properly setup is. You also have to convince the players that your certificates are trustworthy...especially if you generate the whole chain yourself. If you don't want to do this, there are services that can do this for you, but there will be costs involved.

Doing this on a personal level is already quite expensive, on commercial level it becomes very quick very(!) expensive. VeriSign is one of the biggest certificate vendors you'll find. Very expensive, but the least problematic to setup as most, if not all OS's, come with this as standard. Checking for the certificate and for example a MAC address that belongs with this certificate is relatively easy for the one doing the authorization and the user will hardly notice anything from the log in procedure.

Though faking a MAC address is easy, the strength of the authorization lies in the combination of the certificate and the MAC address check.

A good example of this would be how a VPN authorizes a computer to be allowed on its network. That check is done early in the full authorization process. After that the user needs to fill in a user name and password to complete the full authorization process.

[Deozaan]

I think that's part of OAuth or OpenID.

-Deozaan (January 06, 2014, 07:24 PM)

You can do it with both.  OAuth would be much more useful for a non-browser app.

However, my solution would be this:

• Each device/profile gets a GUID on first run.
• Player is prompted to link profile to an email address.
• If they do, send a confirmation email, and add the GUID to a database: [Email address]<[GUIDs]
• Merge data from local profile to email address

The profile ID is a unique identifier. This essentially means you don't need a password, because having the device is enough proof.
Linking to an email address should be optional. Only required if a user wishes to merge to GUIDs into a single profile.
Other than a once off association (Which is optional), the user doesn't need to see the login process again.

-kamahl (January 06, 2014, 07:41 PM)

This sounds very much like it could accomplish what I want to do. However, I see two potential problems with it:

1. I'd really prefer not to have any personal information about the players. This includes email addresses. Though I suppose I could store a seeded hash of the email address and compare it, and if it matches then merge accounts or whatever.
2. I hear stories about people changing some of their hardware (often their GPU) and it invalides their DRM-enabled program (usually a game) because they suddenly have a new GUID or something similar. Though I suppose I don't need to access the GUID every time the game runs. Just the first time to link to their online account and then I can simply store a reference to their account number or whatever and not rely on the GUID.

Are these problems anything I should even be concerned about? If so, do my own suggested solutions seem like they would reliably circumvent the problems? Are there other problems with my ideas that I should be aware of?

[mouser]

You know this falls under the scope of things i'm trying to solve with my Mewlo system - to make it easier for people to create community-based custom web services.

[kamahl]

I think that's part of OAuth or OpenID.

-Deozaan (January 06, 2014, 07:24 PM)

You can do it with both.  OAuth would be much more useful for a non-browser app.

However, my solution would be this:

• Each device/profile gets a GUID on first run.
• Player is prompted to link profile to an email address.
• If they do, send a confirmation email, and add the GUID to a database: [Email address]<[GUIDs]
• Merge data from local profile to email address

The profile ID is a unique identifier. This essentially means you don't need a password, because having the device is enough proof.
Linking to an email address should be optional. Only required if a user wishes to merge to GUIDs into a single profile.
Other than a once off association (Which is optional), the user doesn't need to see the login process again.

-kamahl (January 06, 2014, 07:41 PM)

This sounds very much like it could accomplish what I want to do. However, I see two potential problems with it:

1. I'd really prefer not to have any personal information about the players. This includes email addresses. Though I suppose I could store a seeded hash of the email address and compare it, and if it matches then merge accounts or whatever.
2. I hear stories about people changing some of their hardware (often their GPU) and it invalides their DRM-enabled program (usually a game) because they suddenly have a new GUID or something similar. Though I suppose I don't need to access the GUID every time the game runs. Just the first time to link to their online account and then I can simply store a reference to their account number or whatever and not rely on the GUID.

Are these problems anything I should even be concerned about? If so, do my own suggested solutions seem like they would reliably circumvent the problems? Are there other problems with my ideas that I should be aware of?

-Deozaan (January 06, 2014, 10:08 PM)

I would recommend creating the GUID once, and then storing it, rather than trying to link it to hardware identifiers.
That way, as long as the user doesn't blow away the config files your UID won't change.

The reason I suggested email addresses is that they are something that would be personal enough that people can't impersonate you.  
There would be nothing more irritating than if someone were to get their PC associated with my account, and sell all my items/get me banned from chat/other such effects.
A salted/hashed email is fine.  Just as long as there is a way for the user to be sure nobody else can associate to their account without their knowing.

EDIT: If someone were to clone said config files, and impersonate your GUID, that would still be an issue.  But such things can only really happen with physical access - And when that's true, it's generally easy enough bypass further restrictions anyway.

[TaoPhoenix]

You know this falls under the scope of things i'm trying to solve with my Mewlo system - to make it easier for people to create community-based custom web services.

-mouser (January 06, 2014, 10:26 PM)

Random comment Mouser, sometimes a Framework gets so low level that no one actually works on it!

5% experience, see my pseudo-Nany, that no one touched.

[Deozaan]

You know this falls under the scope of things i'm trying to solve with my Mewlo system - to make it easier for people to create community-based custom web services.

-mouser (January 06, 2014, 10:26 PM)

Yeah, it kind of does. But I think for a web service you can just integrate OAuth or OpenID (or both). Since you're already in the browser it's not that big of a deal to redirect to Google or Yahoo or Facebook or whatever asking for authorization and then redirect back to the Mewlo content to finish logging in.

But in my case, I want players from inside a fullscreen program (my games) or on mobile devices to be able to sync to their accounts without having to be redirected to a browser. And it's seeming to me like it would be a lot easier to have them type in their e-mail address, be sent a link they can click to associate their account with that e-mail, and have it all done automatically for them so they never even need to login.

This would require a few things on the server backend:

1. A new account would automatically be created for each device (GUID) the game was run on.
2. Accounts would need to be easily merged/linked to each other. (i.e. multiple GUIDs per user/email address). This includes non-destructive syncing, so that only the best data is synced (i.e. no progress is lost, best times/scores are not overwritten with worse ones, etc.)

I would recommend creating the GUID once, and then storing it, rather than trying to link it to hardware identifiers.
That way, as long as the user doesn't blow away the config files your UID won't change.

-kamahl (January 06, 2014, 10:43 PM)

My question is more about how the GUID is created. I wouldn't know how to go about generating a guaranteed unique ID, but apparently that's already a feature Unity provides for me. I just don't know if it creates it using hardware identifiers or what. But I think I'd just store it, like you said, and only access it if/generate it if there's no data already there.

The reason I suggested email addresses is that they are something that would be personal enough that people can't impersonate you. 
There would be nothing more irritating than if someone were to get their PC associated with my account, and sell all my items/get me banned from chat/other such effects.
A salted/hashed email is fine.  Just as long as there is a way for the user to be sure nobody else can associate to their account without their knowing.

EDIT: If someone were to clone said config files, and impersonate your GUID, that would still be an issue.  But such things can only really happen with physical access - And when that's true, it's generally easy enough bypass further restrictions anyway.

-kamahl (January 06, 2014, 10:43 PM)

So this is what I'm picturing would be necessary to do it this way:

1. On each device, they'd need to enter in their e-mail address.
2. They are sent an e-mail (for each device) to link the game to their account.
3. They click the link and the server adds a salted hash of the email address to that GUID, and if any other GUIDs have the same hash, all the GUIDs are linked into the same account.

This way if the server is ever compromised, there will be no personal information that can be used to ruin their life elsewhere. No passwords to use to login to their bank account (or whatever), no email addresses to spam, etc.