3 minutes ago, rpiller said:

just using 6 digits

Yeah, a lot of the risk of the reduced keyspace in this scenario is mitigated by having a limited validity window on the access token, so for your use-case, a shorter key should be secure enough.

I'd reconsider just using an access token over 2-factor auth for a couple of reasons however;

• the spamming problem goes away when you authenticate initially with a password
• requiring an password prevents unauthorized access when the token transport (email, sms) has been compromised
• you can allow access to the real account owner in the same event, and allow the token delivery address to be changed if required (i.e. if the device or email login is lost)

I really don't want to store user pw's for all the security reasons which I think are worse than the things you've listed. I keep coming back to the fact that sites that allow you to use social media logins all have the same issues my system has and it seems acceptable for all the sites and apps that use that and it's very common. If I use my email account for this site and my email gets compromised they can log into this site as me. If the transmission is compromised (encryption broken) there is nothing that can be done in any system. The only thing I see is trying to actually ID a person in the case they get a new email or device (if using phone) but perhaps I could use question/answer for that which is less sensitive then pw's. Would still hash those in the DB but still less sensitive.

39 minutes ago, rpiller said:

I really don't want to store user pw's for all the security reasons which I think are worse

That's understandable, it's good you have a strong understanding of the importance of security.  But do keep in mind you will only store a hash of the password, combined with a random salt per user, so the user's original password is unable to be retrieved (assuming a decent hash algorithm is leveraged) even in the event of a data breach.

4 minutes ago, Neil Cross said:

That's understandable, it's good you have a strong understanding of the importance of security.  But do keep in mind you will only store a hash of the password, combined with a random salt per user, so the user's original password is unable to be retrieved (assuming a decent hash algorithm is leveraged) even in the event of a data breach.

 

I believe every company who stores PW's does it that way, yes. Yet when that news of a breach hits people are freaking out and that company takes a hit. I'd rather avoid that completely and be able to say we don't store any user pw's. That's the angle I'm playing here. The fact that your avg user doesn't care what the tech behind pw storage is. They just know, Sony got compromised and hackers have access to passwords! The sky is falling!

Really, given enough time, having access to all that information a hacker can and will crack some of those pw's. Then the company sends the email "Change your passwords and if you used this pw for another change that too!". ick. Want to avoid.

Sony had plaintext passwords. Yahoo had unsalted passwords. All the well-known ones had either plaintext passwords, or significant personal data (addresses or social security numbers or credit cards).

To put it another way, in the event of a data breach, which would prefer to be disclosed:

• all your user's usernames and password hashes, or
• all your user's email addresses and phone numbers?

Well there is a better alternative to passwords but with added completely. Public Key infrastructure. All parties make a key pair. They keep private keys private and use them to attach signatures to traffic before sending. Each party's public key is sent to a certificate authority (like God) who returns it back in a signed container (certificate) indicating they are trusted. The public key is used to verify and private key signs. The certificate acts like a password. Only it expires... and since signing is separate from verification you can't steal identity and impersonate as long as everyone's private key stays private. Clients can authenticate themselves to servers and vice versa. Server authentication much more common (bank websites). Its much stronger than a password, but it's more work.

Quote

I'd suggest that you don't mail a "password" but a one-time-use token.

Yep, that's what I meant. Bad wording if I said otherwise.

The game is a PC game (not web) so I think it's valid if session tokens die after the game closes so I won't be storing them in anything but memory.

The idea of having access tokens that expire in 15 mins is that people need to get their hands on it within that time and use it before you do (they are invalidated after usage in my system) and even then, they get a 1 time access to, in this game, a video game. If I add the phone text as 2 step that's 2 separate things to get a hold of in 15 mins and use. Highly unlikely.

Steam gave me a 5 digit token to reset my pw. Amazon and at least 1 big bank allows you to logon completely with a 6 digit access token if you do "Forgot Password". All delivered through email and only good for a short amount of time. If you have people who know your email pw or sniffing your network traffic, yes you'll have issues. I agree.

Edit:

I've been looking at the Steam API as well since it has a method for this.