Hey People!

I´ve got a question. I´m now at the part where i need to implement a login/register system for my project.
My question would be:
What would you expect from a secure login/registration system?

It would be also good to know "How" to you would implement it.

Keep in mind that the whole process itself is done ingame, so there is no website or anything to login/register. You have to do it ingame.

But you need a webserver/host and thats where it goes:
PHP scripting.
You need to encrypt the password (mostly done by md5 hashing it and then using a salt, so you can send it secure over the internet to your php script).
Never ever save the real password anywhere, just the salted md5.

I'd expect you to use a well tested crypto library with a proven track record and people behind it that know what they are doing. Don't roll your own crypto. Ever.
Use proven cipher suits that do what you want them to do, ie, don't shoehorn algorithms over problems that they are not supposed to solve.

For your server communication, don't roll your own protocol, use TLS! Use certificate pinning to verify that the server is who it claims it to be, use a simple HTTP protocol/RESTful API to communicate.

Don't encrypt passwords. Ever. Use a cryptographic hashing and a random salt for every password, don't re-use salts, that's as good as using no salts. Use something like bcrypt to hash the passwords, use enough rounds (10+) and increase over time.

Don't ever trust anything a client sends you. Every client is a lying, cheating bastard, treat them like that! Verify input, use prepared statements when putting the data into your database. Don't store passwords. Discard them once you are done getting the hash out of it.


Edit: Most importantly: Don't listen to Chaos because he knows fuck all what he is talking about. If someone uses "encryption" in conjunction with a cryptographic hash function, laugh at him and then turn your back to them. If they suggest MD5, a hashing algorithm, that is broken since 2007(!), feel some pity for them and their users. SHA512 at the very least. But better yet, something like bcrypt that allows you to increase the rounds and that is deliberately slow. YES, you don't want a throughput of million of hashes per seconds, you want something that is slow, so brute forcing is slow.

Edit2: Jesus Christ, just reread what he wrote... Did he really say that you should hash it ON THE CLIENT?! Chaos, if you don't know what you are talking about, don't talk! Especially not when it comes to cryptography. Jesus. Fucking. Christ.

@Chaos
There is a webserver, also PHP and everything involved. Just no Webpage to login. This is what i meant.

@JustSid
I really hoped that you reply!
Thanks for your input! I have to do some research first to ask questions.

Cheers!
To expand a bit on my answer instead of just throwing in buzzwords (this is pretty much the longer version of my reply, since I have nothing to do while waiting for my OS to restore):

Use TLS for communication. TLS (or SSL, but we don't call it that way because Microsoft didn't want a Netscape invention to be incoperated into Internet Explorer) is a protocol that takes care of authentication and encryption. The server has a certificate that signed by a CA (certificate authority) and optionally one or more intermediate CA that together build the so called chain of trust: The root CA is trusted, ergo all certificates signed by the CA and its intermediate CAs is trusted as well, ergo the certificate that your server presents is trusted ergo the server is who it says it is. Is the chain of trust broken, the server may or may not be who it says it is and the connection should be refused (the huge red pop-up in browser that says the server couldn't be verified).
The certificate that the server presents is used to authenticate the server to the client (it can also work the other way, but that's rarely done outside of enterprise networks). Once the server is verified, a secure connection is established between the client and server that provides two features: It can't be man in the middled, if someone tampers with the packets between client and server, it's detected.

This leaves you with one problem, any server that provides a valid certificate becomes cool. This is okay for web browsers, but not so much for games. This is where certificate pinning comes in. Since you know your server, you also know in advance which certificate to expect, and you accept nothing but that certificate. This also leaves you with the option to self sign the certificate, which previously you couldn't do (since a self signed certificate doesn't have a chain of trust since you are not a trusted CA. If you'd accept any certificate, anyone could've forged it and presented it to your game and it would just accept it).

Bonus points, create a revocateable certificate. Revocation of certificates is an extension, and a rarely used one. It works by checking the certificate, checking if it is revoked (the certificate includes a field that tells you where to check the status of the certificate), and if it is revoked, you tell the server to bugger off. Why? Because certificates can be stolen! They work using public key or assymetric cryptography, basically a form of cryptography that has two key: A private and a public one. The public one can be known by anyone and can only be used to encrypt data, the private key known to you only must be used to decrypt the data. If the private key leaks, see also heartbleed, your certificate is no longer secure and should be revoked.

So, now you have a secure connection to your server. How you talk with it isn't very interesting, but a REST API is always good and easy to use. Provide a simple set of API endpoints to create users and login users and verify sessions. Maybe also logout if that is something you want (but have internal functions to invalidate sessions, eg when a user resets their password, invalidate all sessions the user previously had).

User creation and password verification: Encrypting passwords is bad, because then you just need a key to get the plain text passwords back. What you want is a cryptographic hashing function, a function where you input something and get a value back from which there is no chance to get the input from. Small variations of the input have huge impacts on the output. On top of that, you want to salt your passwords. This is needed to combat rainbow tables, because, hashing the same input results always in the same output, so there are lists of millions of commonly used passwords and their respective hashes for all flavours of hashing functions.
But! You want to use a new and random salt per password! Keep in mind that the salt is not meant as a super duper secret that protects the user. It's meant to protect the rest of the users! If your database with the hashes leak, the salts can and will leak as well. But, that keeps people from using rainbow tables with a single salt (because from a single known salt you can create a known table and just check all paswords againt that). Having a unique salt per passwords requires the attacker to brute force every single password that he/she is interested in. The majority will be save since it's only worth the trouble for some people.

Now, next up, adaptive hashing functions. Something like SHA512 is nice, since it creates really nice hashes without many collisions (eg two inputs resulting in the same hash). But it has a downside: It's fast. Insanely fast and can be parallalized. That's really cool for brute forcing, but you want to keep people from doing just that! The solution are adaptive hashing functions. They are deliberately slow and can't be efficiently implemented in hardware and/or be parallelized. If it takes 100ms to create one hash, it is still fast enough for your server and authenticiation of the user, but it takes a crapload of time to brute force any password.
The faster computers get, the more rounds you can add to your hashing function, and the longer it will take for it to compute. A battle tested and established adaptive hashing function is bcrypt.

In addition to that if you are going to implement logging in from a game client do not ever store something like a userid/username for successful logins in client(even in memory), use sessions as Sid suggested, and send a session id to the client. And also make sure that session id is also hashed & salted so client can't guess someone else's session id. If it's a game and not a website(that user may be using on multiple devices) i'd also prefer to invalidate any other alive sessions after a new login.

Also, to slow down brute force attacks even more, give user a limited tries, like after 3 unsuccessful login attempts, make them wait like 30 seconds before letting them to be able to try another one. Also make sure that timeout is not session/client based so they can't use multiple sessions/clients to overcome the limit, associate that limit with username. After that 30 seconds if they get their password wrong the 4th time make them wait 30(or even more this time) more seconds, don't just give them 3 new tries after that time. Reject their login attempts straight up and do not even check if password matches so that your system does not run that deliberately slow adaptive hashing algorithms. Though, this timeout thing generally used in systems that can't use that deliberately slow algorithms because of limited system resources and high user traffic.(They use faster hashing algorithms but slow down the brute force attacks in other ways than relying on algorithm being slow.)

And as Sid also said (i just want to highlight) do not trust anything that client sends and make sure they are sanitized before even trying to use them anywhere in your system.

Good points! Just to highlight the difference though, deliberately slow hashing algorithms are your last line of defense when an attacker already has your database! It's not meant as a GUI brute force prevention replacement where you should indeed just tell the user to fuck off after n failed trials.

So you tell me to send the unhashed password to the script so it can compare the one from the sql table?
Where would you encrypt the password if not on client? wtf.

How is hashing on the client and sending it to the server any secure? If I read you right, you are essentially trying to say that that's enoug protection against wire sniffing and the hash can be send in clear text?!
If you send just the hash, the hash becomes your password! Everyone who sees the hash on the wire can afterwards log themselves into your account, how the fuck is that supposed to make anything secure?

Send the password, hash on the server. Let TLS take care of sending the password securely to the server and don't try to invent any pseudo "secure" protocols that aren't secure at all.


And again, because somehow that doesn't seem to stick: Hashing is not the same as encryption! A hashed password is NOT an encrypted password.

In case that wasn't clear, security is god damn hard!

Let's say you encrypt your password on the client, it's secure now, right, because now can read it, right? No!
If you use classical cryptograhy like AES for example, you have to have the key in the client so simply opening the binary will give any attack what they need to decrypt any password! But you are smart, right, so you use public key encryption! Now the only thing an attacker can do is encrypt the passwords, devious!

Well, an attacker will just use a replay attack. Since you have your super secure encryption, you don't need TLS and can send it in clear text... Too bad that that makes you vulnerable to replay attacks. Even worse, you also open yourself to man in the middle attacks because you can't authenticate the server to the client.

But you made this super secure protocol that is super secure, so that doesn't work. Well, congratulations, you just opened yourself up to a timing attack. Of course, a strcmp() on the hash is not an O(1) operation, it's worst case O(n) but if the strings are not the same, it will bail out early. The timing difference allows the attacker to guess the password character by character until they succeed. Don't believe that works? Sure they do

Given how your implemented the rest of your crypto, chances are that you tell the user to try again from the client and your webserver just accepts as many login attempts as possible.

I don't know how to put it mildly, so I'll put it in easy terms: Cryptography is not a fucking joke and no, just because you know how a pointer looks like doesn't mean you can do it. Even people who know their stuff still routinely fail. If your algorithm is solid, you may and probably still are vulnerable to side channel attacks.