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.

If you believe that a user's email is better protected than your website, then yes, mailing the user a link they can click to set up a login session is reasonable.

I'd suggest that you don't mail a "password" but a one-time-use token. You'd store the token, the user id, and the time it was generated in some semi-permanent storage. When the user visits the "use token" link, you verify the token against the database, emit a login cookie, and remove the token from the semi-permanent storage. Some background task removes tokens that are too old to be useful.

A decent way of generating unique tokens is to base64-encode 16 or 32 bytes that you read from /dev/urandom. A decent storage for semi-permanent data like this might be memcached, although unless your volume is "web scale" you don't need anything fancier than a database table.

The session that you generate lives in a cookie, if you're in a web browser; the cookie is another random token that maps to session storage that in turn stores which user ID and end-of-session-date is used. Some people use 30+ day session lifetimes; some use 1-day lifetimes, for your use case it sounds like an 8 day lifetime with auto-refresh if it's used for more than a day would be alright. That lets people play once a week without having to re-authenticate through email or phone.

Regarding storing passwords, you want to use something like bcrypt() or scrypt() to have an expensive one-way hash function from password+salt to verifier; that lets you verify that a user provides the right password, without there being any kind of "rainbow table" backwards attack to recover the password.

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.

On 3/4/2018 at 3:39 PM, rpiller said:

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.

That is because there is a high amount of high profile companies using extremely poor security practices. Yahoo! had their passwords stolen which were stored using MD5. LinkedIn was using unsalted SHA-1.

They failed at basic security implementations that should be embarrassing given their size.

Any strong password implementation should use salted bcrypt2 passwords, and the password exchange every time you login must happen adding extra randomized salts. Thus the passwords are never exchanged in plain text, the hashed password exchange is never the same twice (thus preventing spoofing) and if the passwords database gets stolen, it would take significant time (years) to crack them.

The problem with emailing tokens is that emails are sent in plain text format and ping with a lot of servers. It's SO easy to steal them without you ever knowing (and without having to hack your email credentials in any way). I don't want this topic to become political, but that's why the investigation about Hillary Clinton is so important: she store confidential information in her private email account. Regardless of why she did it or whether she should have done that, doing that is extremely insecure.

Basically, sending emails is is the equivalent of shouting extremely loud in public. Everyone knows.

You can use public/private key encryption for emails, however that creates the problem of telling people to send you their public keys, which you'll have to keep in a database that can get stolen.

Yes, stealing a public key is worthless. But I could argue so is stealing a salted bcrypt2 hashed password. Also if hackers manage to steal your private key, they can now impersonate you.

Yeah, you can try to revoke your private key. But so can you ask the users to reset their passwords.

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.