—
I'm not too educated in this matter but I spent several days trying to figure out a solution to something I learned. I wanted to make a tutorial at some point but I didn't want to mislead if there was something I missed. Therefore, feel free to look deeper into the things I mention- if you have concerns. I wont be sharing code at this moment. I also wont be writing those tutorial pages (yet anyway). I'm just going to give you way more than you asked for in one post. It will perhaps come in handy for you or anyone who searches this in the future- and so here we go.
I'll start off by saying this. If you're doing operations on the client-side a person who wants to attack knows exactly what you're doing. Never depend on the client-side. Never trust the client-side. It can be manipulated. So the best way is to always design away from a client dependency.
Now. I don't recommend sending passwords in plain text on the basis that it's the most frowned upon thing. A single encryption on the client-side should be fine. Do not mix encryption unnecessarily. It will weaken your encryption when you're not careful.
You're going to want to get an SSL Certificate. These can be moderately difficult to understand at first. I'd go way more in-depth but this post would be giant. You can get a cheap SSL for around $10 a year. RapidSSL, Comodo, TrustSSL(GeoTrust), DigiSign, Verisign. You'd primarily want one of these, and for this- preferably the cheapest.
It will latch onto ONE domain (example.com) and the immediate subdirectories (example.com/*). It will not latch onto, (*.example.com) or any of those subdirectories (*.example.com/*).
Wildcard SSL exists and covers the domain, subdomains and all subdirectories (*.exampledomain.com/*) but they're a lot more expensive ($100+). I don't think you'll need Wildcard or an EV SSL, so don't be too concerned with those.
SSL is great. It helps give an extra layer of confidence to your members. The most important part here is that it will encrypt information that transfers over the line. It will also help indicate if something seems tampered. Although this is a huge plus, it comes with some drawbacks. Things that come from non-SSL connections will sometimes get blocked by your browser. You can also encounter things such as Cross-Domain and Cross-Origin more frequently. However, it's all part of the development process and it feels good once it's done.
Note: exampledomain.com IS NOT secure. You have to use https:// and you can use exampledomain.com as the port is not what is important.
So, with all this you should be able to get the data from the client to the server. The important part now is storage. SHA and MD5 are very fast encryption methods. This sounds good on paper but is horrid against crackers.
There is a fancy way of offloading a particular cracking to a graphics card. SHA/MD5 being run through multiple machine's graphics cards can hit up to millions of attempts every second. A lunch break could become disastrous for many people.
Now, this would most likely only be the most determined of people out there. You'd have to paint a huge target on your back to piss them off. Maybe you could *shrugs*. There is a possible protection from this.
There is a method called PBKDF2 which will run a SHA512(or 256, not sure which) over and over to the extent that you specify. The more times the better. It connects something called a Unique SALT value to the password and re-rusn the encryption thousands, ten thousands and hundred thousands of times making it require more resources to hack.
Another newer method is called SCRYPT. This hasn't been tested too much so it's not openly recommended. However, this method takes an increased amount of resources. This would essentially mean it is very difficult to crack these values. This of course depends on the settings you specify.
You can find PHP libraries of PBKDF2 and SCRYPT. You can find NODEJS libraries that can help do this in Javascript alongside Socket.IO.
Now I told you it would be easy to understand. Well- at the core of it- it is. The true issue is that PBKDF2 and SCRYPT can skyrocket the CPU usage and RAM usage very easily depending on the settings you choose. Keeping them lower, you might be fine. However, if a lot of logins have to be processed at one time- things get very complicated.
I'd recommend trying them on low settings and going with that. I wont be sharing my code any time soon (as I'm still using and developing it) but this is some idea of security. It's tough. I just hope I could clear something up for you.
I wont go into details but also look into something called Cloudflare.
Note: Make sure to understand what they do with SSL because if you buy a certificate it wont work with their Free nor the $20 plan.