Is this login security enough?

Question

I'm coming up with my next login system for admins of an e-commerce website, which will have this:

• login form is SSL secured
• password is converted to SHA-256 before being transmitted (bcrypt is too slow still for JS/browser client)
• bcrypt stored hashes (I don't want my database if ever stolen to easily be broken)
• hashed password is encrypted with private key stored as constant in app or file
• a hash of all the important login database values for that user, so that if they are changed via injection somehow, the hash won't match up and the account gets locked out
• recaptcha upon first login failure
• login strike system per device, so if the user tries 5 different logins and they're all wrong, he's out - it's not 5 per login
• second step auth. using SMS, email or AlterEgo - maybe once per device + location and to be used if you want to change your password
• if logging in from a different location different from history, send SMS or email to user
• if device or location information changes while logged in, kill session (to prevent session stealing)
• allow login history to be scrubbed of old devices (users can remove devices they no longer use)
• have option to save login device + location in history (i.e. don't use this option if your at a netcafe or a public network etc.) so it will always ask for your second step

Is this login security enough? Do you think I'm going overkill?

Answer 1

Beware of overkill, it is counterproductive. If your login system is too inconvenient or annoying, users will actively try to work around it. "Users", here, includes application developers and server administrators.

login form is SSL secured

This one is the most important, but not "alone". Theoretically, the whole site should be secured with SSL, not just the login form. SSL provides confidentiality with regards to eavesdroppers, but if it results in a cookie which you afterwards send in the clear to maintain the session, then an eavesdropper just have to send the same cookie to hijack a session. If only the login form is SSL-protected, the only security you get here is in combination with a thorough anti-phishing training: you educate the users into refraining from sending their password to sites which do not have SSL active, and therefore you need a SSL site yourself. But that's marginal.

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client)

This one is useless. It just means that the SHA-256 result is the password. If it can be grabbed by an attacker, then the attacker can use it to log in, without even knowing the "true" password.

hashed password is encrypted with private key stored as CONSTANT in app/file

This feature is a security gain only in the situation where the attacker could get the hashed passwords but not the application files themselves. Whether this is a realistic situation is debatable. On the other hand, that constant key will annoy administrators when the application is to be updated, and may incur extra downtime (it is so easy to forget it when deploying...). Also, this makes confidentiality of the application files an important goal, which is rather uncommon.

recaptcha upon 1st login failure

This will be more annoying than secure.

login strike system per device, so if the user tries 5 diff logins and theyre all wrong, he's out. its not 5 per login

Don't block accounts, just add delays (e.g. one minute). Otherwise, anybody can lock the account of anybody, which is a problem. Counting tries per device is good, but is subtle, and can backfire: there are some networks (including ISP) out there with massive NAT or proxying, which turn into, from the server point of view, thousands of login requests from the same source IP.

2step auth using sms, email? or AlterEgo - maybe once per device + location and to be used if you want to change your password

if logging in from a different location different from history, send SMS/Email to user

SMS may annoy users: they do not work well for international users, they require a functional mobile phone on the spot, and some people are charged for the SMS they receive (it depends on the country and mobile phone provider). Email is marginally better (but, of course, not if the application you are trying to protect is a webmail...).

have option to save login device+location in history (ie dont use this option if your at a netcafe or a public network etc) so it will always ask for your 2step

Note that in a netcafe, security goes down the sink. A key logger is just too invisible. There is not much you can do against that.

So think I'm going overkill?

Yes. But, more importantly, you also lack the important feature, which is site-wide SSL.

Answer 2

The key factors I always look for in a Project Definition spec are missing here:

What are you protecting? Who are you protecting it from? What is the impact if it is compromised?

If you are protecting your list of friends birthdays it is almost certainly overkill. If you are protecting Top Secret material from International or Corporate espionage then it may well be too weak.

You need to think about the potential risk, the threat actors who may target you, and other factors such as resiliency (does a failed login on a Monday morning make it exceedingly difficult for a user to gain access when they really need to)

Hopefully you do have answers to these, but unless you post them here it can be hard for others to provide guidance on security architecture.

Answer 3

You're using lots of security buzzwords here - but the end result is not as secure as should be, and as Lucanos says there's a lot of redundancy.

Go read this thread.

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client) bcrypt stored hashes

Does that mean you generate a bcrypt hash of the sha256 hash of the password? Without a salt the sha256 password does nothing to help the security, and using a second round of hashing doesn't help either.

hashed password is encrypted with private key stored as CONSTANT in app/file

What? Why? Do you ever want to recover the hash of the hash of the password? Even if you did, the way to do this would be to encrypt using a public key.

recaptcha upon 1st login failure

Doesn't add a lot of value.

if device/location information changes while logged in, kill session

So we're talking about session management as well as authentication - in that case you've still got lot of work to do.

Answer 4

There's a few things I don't get here, and probably one or two things worth adding:

• hashed password is encrypted with private key stored as CONSTANT in app/file

As a "CONSTANT" - what does that mean? Is it hard coded? How is it protected. I agree with other posts that a salt is a good plan - if you salt and hash the passwords, I don't see a need for the encryption on top of it. And - if the private key for your encryption is stored in a flat file or hard coded in the app, you have a weakness there. Recommend finding a way to better protect this key.

• "per device"

In a number of places you mention that you're tracking behavior "per device" - what does that mean? How are you determining what the device is? You're implying a type of device authentication here, and from what little I know about this area, most ways are immensely spoofable, and the ways that are not require issuance of devices from a trusted point, which can greatly change your model of operation.

In places where you say "per device", you're going to have to think through what it means if the device is faking your system. Also, if you have decided that "IP Address" = "device", then you may have to consider numerous situations where the user's IP address is changing through no fault of the user.

• allow login history to be scrubbed of old devices

Is that something you are fully prepared to support? Scrubbing, say, a cookie is pretty easy, but do you mean all parts of memory? Personally, if I were making this promise, I'd bound it some way so that if login information was put someplace strange by the OS, that it wasn't a breach of what my system had promised the users.

I also see some issues:

• How can a user recover from a lost/forgotten password?

I see you citing a fairly involved process for password change. If this is a casual web system, I would bet money that this will be your least used feature. Instead, user's will drift away from the system, only to return and need their passwords and have completely forgotten them (or they wrote them on a sticky note on their screens... that's even worse).

You'll need a way to do password recovery/reset that fits your high-protection model. Is it staffed by a person? Do they have backup questions to answer? Do they get a reset password emailed to them out of band? Each recovery mechanism has risk, and generally less risk = higher cost - for example, my credit card company's ultimate identity check for issues like this is a painful Q&A with a live person about my purchasing history. Very good, but expensive in terms of that person's salary.

• Simple way for users to vet the system

The credential presented by the server in SSL should be good enough, but very few users are PKI savvy enough for that. I know that big financial institutions have started making use of words and pictures selected by the users that users are supposed to verify during login. The whole goal here is to avoid a situation where a phisher could send your user an email directing them to "paypa1.com" (a number 1 not an l), and get their passwords. Since you do have features that accommodate remote login, your attacker will then be able to use a legitimate user account from any system.

• Other Social Engineering

These two issues probably aren't the only human-oriented processes you'll need to think through - do you log accesses? Do you have a plan to separate login auditing from administration privileges? How much access do admins have and how is the system protected from them? Are there any other social engineering attacks that might work?

So far, what you outline is tech-heavy, and human-light - you're talking about a couple of mechanisms that may have usability impact, which could result in users not using the system, or users taking steps to hack the system to make it easier to use, and I'm concerned that you haven't thought about the attack vectors of a social engineer. Like water, hackers will find the crack or crevice that is easiest to use.

I'm hitting you with the heavy stuff here, because my perception is you're trying to design something somewhat high end for something that is presumably high risk. If that's what you're trying to design, then you have to back up and see the whole system - your user community, birth to death of accounts, behavior within the system and the risks of bad behavior.

Answer 5

I'm just going to proffer a few questions to try and 1) educate myself and 2) give you a different perspective on the system:

password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client)

If you are using an SSL connection to begin with, do you need to do this? Even in the event that someone was able to intercept the hashed password, how is that more secure than intercepting the plaintext password? If I was able to spoof the login and send the same hashed payload, how is that any different?

a hash of all the important login database values for that user, so that if they are changed via injection somehow, the hash wont match up and the account gets locked out

So, if the user updates their email address, or password, the hash will change and the session will terminate? Or do you have safeguards to allow for these, legitimate, changes to be handled?

if device/location information changes while logged in, kill session (to prevent session stealing)

Not 100% sure about this, but could this mean a mobile handset might be kicked from a (legitimate) session if it transitions from WiFi to GSM/Cell, GSM/Cell to WiFi or possibly within the GSM/Cell network (if it changes the public IP address presented by the device)?

login strike system per device, so if the user tries 5 diff logins and theyre all wrong, he's out. its not 5 per login

How are you tracking "per device"? By the IP address? It can be shared. By a cookie? It can be purged. By a User-Agent string? It, too, can be changed.

Aside from these, some of the other ideas sound nice.

Answer 6

ok so this is what i've learned from everyone's responses

• Use SSL, no need to hash the password client side as its pointless, SSL is the right way to protect from sniffing.
• Use BCrypt (w/ Salt) to store the password hash, SCrypt if I can find a PHP implementation of it.
• Don't lock down login for failed password, just use an increasing time limit to prevent DOS. Ofcourse log the failed attempts down and alert admins if its getting to be unusually high.
• encrypting and rehashing the passwords is pointless
• consider ways to vet the system and to prevent social engineering
• force long and hard passwords on users, like use passwdqc to check and let users know what passwords are expected of them.
• locking down because of device/location changes can be problematic on Cellphones, wireless or some ISPs, consider maybe just logging out of session.
• need to properly implement session management
• admin session should stay within SSL area.