Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm coming up with my next login system for admins of an ecommerce website to have

  • login form is SSL secured
  • password is converted to sha256 before being transmitted (bcrypt is too slow still for JS/ browser client)
  • bcrypt stored hashes (i dont want my database if ever stolen to easily be broken)
  • hashed password is encrypted with private key stored as CONSTANT in app/file
  • 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
  • recaptcha upon 1st login failure
  • 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
  • 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
  • if device/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 (ie dont use this option if your at a netcafe or a public network etc) so it will always ask for your 2step

So think I'm going overkill?

share|improve this question
1  
... you're not salting your password hashes? –  bdonlan Jun 21 '11 at 3:00
1  
Overparanoid, but looks good for me ;-) –  zerkms Jun 21 '11 at 3:01
    
ah yes bcrypt with salt ofcourse –  kzap Jun 21 '11 at 3:04
2  
The only thing you're missing is quantum encryption :) –  Sergey Akopov Jun 21 '11 at 3:09
5  
The chain is as strong as the weakest link, don't forget that. –  Incognito Jun 21 '11 at 13:20
show 5 more comments

migrated from stackoverflow.com Jun 21 '11 at 13:13

This question came from our site for professional and enthusiast programmers.

6 Answers

up vote 12 down vote accepted

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.

share|improve this answer
    
I wont be bringing the SSL session outside the secure directory. the cookie will be SSL only, so the session wont persist in the nonSSL environment –  kzap Jun 21 '11 at 16:26
    
If he identifies the system by a user agent fingerprint or something, he'll be in better shape than if he goes by source IP. Still shouldn't block, though; and captchaing after 1 fail is too much--an online brute force will take so many more than that... –  user502 Jun 21 '11 at 17:09
add comment

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.

share|improve this answer
1  
I came here to write that as a comment. Gave you +1 instead. –  user185 Jun 21 '11 at 13:30
1  
Well, now that last part looks infinitely recursive, doncha think? ;) –  AviD Jun 21 '11 at 13:41
    
@AviD - maybe I'll delete the last sentence:-) –  Rory Alsop Jun 21 '11 at 14:19
    
Its protecting an online ecommerce store from. Protecting from hackers, competitors, phishers, and admins who use weak passwords or have their logins compromised. If someone really needs to gain access and theyre locked out, its worth it to call and wake up someone who can do something about it. –  kzap Jun 21 '11 at 16:11
    
@kzap - based on your comments I would take @ThomasPornin's answer:-) –  Rory Alsop Jun 27 '11 at 19:20
add comment

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.

share|improve this answer
    
i dont really want to recover the hash, maybe just to encrypt it more again later down the line. a lot of hashes are being broken nowadays with GPUs. –  kzap Jun 21 '11 at 16:48
    
Storing with bcrypt is much more secure than storing a sha256 hash; but the first hashing is redundant, yes. kzap, if you're worried about GPUs use scrypt instead of bcrypt; it renders GPUs and FPGAs obsolete with memory-hard functions. –  user502 Jun 21 '11 at 17:13
add comment

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.

share|improve this answer
    
sorry i didnt make it clear, its more for a ecommerce site administration and not for the general public. Password reset would probably entail a phone call to the sys admin and its worth it. Thanks for the tips on vetting the system and social engineering. I think a good 2step would prevent social engineering. especially if its a onhand device/key/cellphone –  kzap Jun 21 '11 at 16:23
    
If you think security is going to be helped by a portable device... think again. Most people enable their smart phones, pads, or other portable computers with so many default/auto logins that most if not all secondary channels will be wide open if the device is lost or stolen. If this is a work thing, you might think about one of the two steps being to a work based voicemail that's in a mail box system where password protection is enforced. –  bethlakshmi Jun 21 '11 at 18:20
add comment

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.

share|improve this answer
    
* password is converted to sha256 before being transmitted - Yes its not more secure, i just prefer it over sending it plaintext incase I ever use the script on a NonSSL page. * a hash of all the important login database values for that user - Yes if any values like password, email, cellphone, 2step device id are changed, the hash gets updated with the new hash. Maybe i should encrypt the hash also just for fun * login strike system per device - I like to track per device using something like evercookie or a number of things like IP+Useragent+Location . combine sys values and hash it :) –  kzap Jun 21 '11 at 3:15
3  
@kzap "just for fun" is a terrible reason to be doing things in security, especially for crypto - odds are, if you dont have a real reason to do it, you're just going to make it weaker. In this case, encrypting the hashed password wont help much, since you should be having SSL anyway - and if you're encrypting it clientside, that means the key is exposed to all other users. To fix that you might try... stop, dont do that, you'll just try to reinvent SSL. Down that road lie madness (and insecurity). –  AviD Jun 21 '11 at 13:46
    
@Avid *noted... –  kzap Jun 21 '11 at 16:19
add comment

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.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.