I'm making a online game where I need to preserve some things for the players so each will have an account. However, I don't want to get into the business of storing user created passwords since that's dicey these days.

So I was thinking what's the point of even asking for the user to create a password for most apps these days? With the advent of phone/email verification why not just have the user enter their e-mail address and id at registration time and then have the server create a temp pw good for 15 mins and then send it to that email address and have the player copy/paste that into the game to login? A phone number could be used as well. This is usually step 2 in a 2-step auth these days anyway so since it's, I'd say, more secure than the user generated pw per app, why not just make that the only step?

I get the slight inconvenience but I think people are getting over that these days because of security and this step is becoming more popular. This seems like it passes the buck to the email provider and their security which will be better than what most people with an app come up with. To prevent someone who knows your email and the app from spamming, the system could track last temp pw try and only allow so many in an hour.

Thoughts on this approach in terms of security?

I have too many questions to ask, but reading on about OAuth2 is probably a good first idea.

Quote

Because email addresses and phones get stolen all the damn time.

And the worst that happens is you can't play my game under that account anymore as my game stores nothing else about the user. Of course have a way to call support and xfer account.

11 minutes ago, rlyeh said:

I have too many questions to ask, but reading on about OAuth2 is probably a good first idea.

I have looked up on OAuth2. From my findings it seems like it's more for authorization of resources to another app but some people use it as authentication which some have declared not ideal and sort of a side effect and can easily be done incorrectly. Not to mention OAuth is a pain when you're not dealing with web technologies for games.

21 minutes ago, Promit said:

Because email addresses and phones get stolen all the damn time. The idea of two factor authentication is to avoid having a single point of compromise become built into a major breach.

Everything gets stolen all the damn time. Even passwords to sites. I use google auth for this very site. If someone steals my email pw they can now log into this site as me. Same idea. That method I propose seems just as secure as a method used to access this site, but I suppose adding phone too would make it better.

2 hours ago, rpiller said:

storing user created passwords

You're right, you definitely *don't* want to store the passwords. Or even temporary passwords.

As mentioned, OAuth2 is a good way to hand off the responsibility but requires an interactive browser session for the user to confirm.

So assuming you can't/don't want to leverage OAuth, and you want the user to log into your service directly, you'll have to learn about effective password hashing methodologies.

This page has a great write-up on the process, potential pitfalls and how to do it correctly.

https://crackstation.net/hashing-security.htm

4 minutes ago, Neil Cross said:

So assuming you can't/don't want to leverage OAuth, and you want the user to log into your service directly, you'll have to learn about effective password hashing methodologies.

This brings up a good point. I was first thinking of storing the temp pw in the db user record, but I don't need to do that. I can just store it in memory of the running server app.

Why do you say look at password hashing with the way I'm thinking. These "temp pw's" will be GUID's and stored in memory only on the server along with a 15 min timeout on them. When the user first connects it sends his email address that he enters into the app to the server. The server sends a new GUID to said email address. The user takes this GUID from his email address and enters this GUID into my game. That GUID goes to the server along with his email address again where the server validates the 2 match in the memory container (and also that it isn't expired) and now the user is logged in. I mean I guess I could hash the temp pw/guid that's stored in the memory of the server app for added protection. As long as the transmission is secured I guess I'm not seeing any security issues with this.

As stated if someone gets into a persons email account they can already have access to anything that user granted OAuth access to before like every website in existence these days. So it's not as if OAuth protects against a persons email getting hacked which allows the granting of authorization on so many things.

So you've outlined how the user logs in the first time, but what about subsequent times after their account has been created? (i.e. after a reinstall or on a different device).    Be sure keep in mind the added risk you take on by storing a mobile number, and the cost/complexity of sending the password keys over SMS (if that's what you go with).

In-memory is a reasonable idea, but it won't scale horizontally if you need to increase the number of servers you use, or if your process crashes or server reboots.

I'd also suggest you consider a random string key rather than GUIDs, sure they're long, but they have a limited character set (0-9a-f), standard pattern and fixed length.  I've not done the numbers, but ff the top of my head likely an alphanumeric password with length 9-12 could even provide a larger keyspace than a full GUID.  They're also a pain to copy over if you're unable to copy/paste the code.

Hope that helps.

n

37 minutes ago, Neil Cross said:

So you've outlined how the user logs in the first time, but what about subsequent times after their account has been created?

Same process. I'll for sure have a users table but it'll just have an email/phone field(s) so users are ID'd by their email only. I will for sure have to take a non spamming feature in since if someone knows you play this game and your email you use for it they could just keep requesting access tokens which we don't want but that should be easy enough to stop a spam of those. Once you're actually logged in any other requests for a token will be denied until you're logged out (which info is stored in memory of the app).

40 minutes ago, Neil Cross said:

In-memory is a reasonable idea, but it won't scale horizontally if you need to increase the number of servers you use, or if your process crashes or server reboots.

Since this is just for authentication crashes or reboots causing a logout is fine with me I think. Scaling horizontally I think would just be servers can only play against people on those servers so we'd have a cap of users per server. If it even got to that point

41 minutes ago, Neil Cross said:

I'd also suggest you consider a random string key rather than GUIDs, sure they're long, but they have a limited character set (0-9a-f), standard pattern and fixed length.  I've not done the numbers, but ff the top of my head likely an alphanumeric password with length 9-12 could even provide a larger keyspace than a full GUID.  They're also a pain to copy over if you're unable to copy/paste the code.

That's a good idea! Thanks for that. I will have a button they can press that will copy from the clipboard so this is perfect.

The more I think of this the more I remember Amazon and a popular credit card site allowing a 6 temp digit access token instead of a password. I was shocked when I saw that option after pressing forgot password and it was slick. They were just using 6 digits!