Question

I’ve never written a user auth system before and for this project I need to balance security with efficiency (meaning I can’t spend hundreds of man hours working on the security end of this, but that I need to keep passwords and login info secure).

I’m using Node.js with the express framework and passport for authentication and sessions.

The research I’ve done so far shows three problems to solve. Before today I had literally no idea what if any common solutions exist for these problems, and a few hours of randomly pecking away at the research isn’t giving me confidence in the completeness of the answers I’ve found.

The problems:

1. Do not store plain-text passwords unencrypted in a database
   (Possible answer: salt/hash the password ON THE SERVER and store the hash in the database.)

2. Do not pass plain-text passwords over non-secure http connection
   (Possible answers: A–Use Https ONLY for the authentication process. After that use http. B–Send a random salt to the user at the login page, hash the password client side, then un-hash and re-encrypt for database storage.)

3. Do not use weak encryption methods that GPUs can crack at 700,000,000 passwords per second.
   (Possible answer: bcrypt)

These are just the most sensible possible answers I’ve found in 3 hours of research. I have no idea whether these are sufficient, what their weaknesses are or what alternatives might be available. I’d appreciate any further insight (Also note: I’m not even sure–does https protect the password sufficiently as it is transmitted?)

Answer 1

The best practices for security are many, but the idea is essentially the same: hope for the best and expect the worst. That explains your three problems:

1. Assuming someone gained access to your database, you don’t want the possibility of passwords being compromised. Hashed passwords guarantee that you cannot get the password from the hash.
2. This is to avoid from middle-man attacks. A server could easily listen and record the password as it passes requests to and from your server. Even if you don’t think a middle-man attack is possible, hope for the best and expect the worst.
3. Use a long password that is easy to remember but difficult for others to guess. Better still if you can limit the number of attempts to 3 every 5 minutes since that would require a multitude more time to crack.

Each of these three pivot on the idea either that someone has cracked your system and to do damage control or to make it near impossible to crack due to the sheer time it would take. Performance is important but always less important than security. Just use common sense mainly and don’t compromise security based on assumptions, since that’s the surest way to insert errors in your security. In short, hope for the best and expect the worst.