I want to put a measure in place to stop people from trying to hack user accounts on my website. What would be the best process behind this without being annoying to a customer who just needs to try a few passwords to remember?
I notice Google shows up a captcha image after a couple of failed attempts. I've never tried hard enough but I'm sure they must block you after quite a few attempts.
Would would be the best practice to ensure that someone doesn't try a brute force approach to gain access to an account?
captcha ?
Blocking their IP Address (does this work if they're on a shared IP)?
Your best bet is to lock out(10min, 15min, etc...) on a per-username basis with a relatively high number of tries possible(10 or 20 or so) in a set period(e.g. rolling 30min window). By setting the number of tries higher than 3 or 5, the average user will either give up or attempt to reset their password before the lockout hits.
You may consider logging failed attempt data(IP, username, timestamps, ...) to understand behavior differences between normal user behavior and brute force attempts. This will allow you to refine your policy over time.
Also consider a strong password policy(at minimum 8+ characters with at least one number).
You may also consider some form of multi-factor authentication. You mentioned captcha but there are many other techniques you may find useful. One site I work with will email a token to a user's email address if they do not recognize a user's IP address and the user must present that token before they are able to access from the new IP address.
Schemes that lock a user out after a certain number of attempts and/or extend the time that it takes after further login attempts are accepted again are certainly a good idea. As are CAPTCHAs (aside from being annoying :) But, in my opinion, they only make sense if you have strong hardware backing you.
The reason why I believe this should only be tried if you have the resources to do so is that you have to keep in mind that a scheme like that requires you to remember the attempts recently made for potentially every user in your system. Certainly, there are numerous ways of persisting the information, varying in their effectiveness: in-memory cache, database, etc.
But no matter what, such a mechanism will put additional load on your application, and there's the downside: if an attacker gets bored or annoyed by your app, they might as well try to take it down with a denial of service attack. And complicated login schemes that need to persist a lot of information will help a lot in achieving that goal.
If you decide to apply such a feature, I would recommend you stress test it a lot in a lab first to get a feeling for "how much you can take" - this way you'll find out if you need to upgrade your hardware :)
An easier way that can do without the need for persistence is to apply a password hash like PBKDF2, bcrypt or scrypt. These artificially slow attackers down enough to make it as hard as possible for them. But be aware, that these, too, put additional computational strain on your application (although presumably less than the aforementioned measures), so again I would do some stress tests first.
Related
I'm on my last steps to open my website, but the only thing that drove me crazy is the php user management. I found a lot of resources about building these systems and I believe that I can write them in my own way. The thing is that when it comes to security I get so freaking out what to go with. For example, when it comes to sending sensitive information over SSL, some people suggest to make sure that the info is encrypted in the registration form so that attacker can't hack it. And some other suggest to make sure that the debugging messages don't show when an error happen so that the attacker can't retrace the links .etc.
now as I read from here and there that md5 is not safe anymore so I'm wondering how would hash new user password and etc... I found a link to some programmers who already offer some user management, but not sure if they are good enough since I'm concerned about security as a priority CodeCanyon
so now what are the security measures that I have to be focusing on?
are there any resources related to that?
Thanks,
You don't have to (you shouldn't) choose between the different things people tell you to implement. Good security is always layered, meaning that you implement as many protections as you can. This approach has multiple purposes. Each layer can prevent different attacks. Each layer can prevent attackers with different experience. Each layer can increase the time needed for an attacker.
Here are some tipps useful for authentication systems.
Don't show debugging outputs
Don't use MD5 hashes. SHA2 or even better, bcrypt are much better
Use salts when storing passwords
Use nonces on your forms (one time tokens)
Always require SSL encryption between server and client
When accessing your database on the server, make sure that information leakage or its client-side manipulation not possible (eg.
avoid injection attacks, with database drivers use prepared
statements, etc.)
Make sure all failed logins (no matter what the reason) take the same amount of time to prevent timing attacks
When a logged-in user starts a risky operation (changing pwd, payment etc.), re-authgenticate him
Never store passwords cleartext, not ever, not anywhere
Require a minimum complexity for the password
!!! Secure your php sessions (another large topic, worth its own discussion) -
As you can see, there a lot you can do (and more people will probably tell you even more stuff), what you really should do depends on the risks you are willing to accept. But never rely on a single security measure, always have a layered approach.
Answering your direct question: It has been proven that MD5 does have collisions and there are rainbow tables floating around (see Wikipedia). PHP does have quite some hash functions available all having different advantages and disadvantages. Please also see the comment section on php.net.
Concerning general web application security I'd recommend you take a look at the OWASP project that is about making web applications more secure. A good start would be to take a look at the Top Ten security vunerabilities ("Top Ten" in the blue box).
use sha1 for storing password , prevent sql injection and xss script as input field.
session hijacking , fixation prevention.
At first you should send your data via SSL (TSL) to the server, this will encrypt. Also you should use a CSRF protection for any form you send to the server.
When you have implemented your functions and they work you should try to hack your site by yourself. Try to inject SQL, JS through the forms, try to manipulate the date after the form was send, you can also try to produce erros that will be written to you PHP error log even that could be executed if your server settings are weak. (http://en.wikipedia.org/wiki/Hardening_(computing))
When you store the password in your database use an seeded hash function, if anyone is able to hack your database and get the hashs he will not be able to encrypt them without the seed.
Your will find many information about all the techniques via google.
In a recent project I put a captcha test on a login form, in order to stop possible brute force attacks.
The immediate reaction of other coworkers was a request to remove it, saying that it was inapropiate for that purpose, and that it was quite exotic to see a captcha in that place.
I've seen captcha images on signup, contact, password recovery forms, etc. So I personally don't see inapropiate to put a captcha also on a place like that. Well, it obviously burns down usability a little bit, but it's a matter of time and getting used to it.
With the lack of a captcha test, one would have to put some sort of blacklist / account locking mechanism, which also has some drawbacks.
Is it a good choice for you? Am I getting somewhat captcha-aholic and need some sort of group therapy?
Thanks in advance.
Just add a CAPTCHA test for cases when there have been failed login attempts for a given user. This is what lots of websites currently do (all popular email services for instance) and is much less invasive.
Yet it completely thwarts brute force attacks, as long as the attacker cannot break your CAPTCHA.
It's not immoral per se. It's bad usability.
Consider security implications: the users will consider logging in to be time consuming and will:
be less likely to use your system at all
never log out of your system and leave open sessions unattended.
Consider other forms of brute-force attack detection and prevention.
Captcha isn't a very traditional choice in login forms. The traditional protection against brute force attacks seems to be account locking. As you said, it has it's drawbacks, for example, if your application is vulnerable to account enumeration, then an attacker could easily perform a denial of service attack.
I would tend to agree with your co-workers. A captcha can be necessary on forms where you do not have to be authorized to submit data, because otherwise spambots will bomb them, but I fail to see what kind of abuse you are preventing by adding the captcha to a login form?
A captcha does not provide any form of securtiy, the way your other options, like the blacklist, would. It just verifies that the user is a human being, and hopefully the username/password fields would verify that.
If you want to prevent bruteforce attacks, then almost any other form of protection would be more usefull - throtteling the requests if there is too many, or banning IPs if the enter wrong passwords too many times, for instance.
Also, I think you are underestimating the impact on usability. A lot of browsers provide a lot of utilities to deal with username/password forms and all of these utilities are rendered useless if you add a captcha.
I would like to address the question in the title—the question of morality.
I would consider a captcha immoral under the following circumstances:
It excludes participation in the application to those with physical or mental challenges, when the main portion and purpose of the application would otherwise not make such an exclusion.
The mechanism of the captcha exposes users to distressing language or images beyond what would normally be expected in the application.
The captcha mechanism as presented to the user is deceptive or misleading in some way.
A captcha may also be considered immoral if its intent is to exclude genuinely sentient machine intelligences from participation for reasons of prejudice against non-humans. Of course, technology has not yet advanced to the level at which this is an issue, and, further, when it does become an issue, I expect human-excluding gates will be more feasible and common.
Many popular (most used) mail server doesn't have it?!
I have a doubt concerning how to store a password for usage in my application. I need to encrypt/decrypt data on the fly, so the password will need to be somewhere. Options would be to have it hard-coded in my app or load it from a file.
I want to encrypt a license file for an application and one of the security steps involves the app being able to decrypt the license (other steps follow after). The password is never know to the user and only to me as e really doesn't need it!
What I am concerned is with hackers going through my code and retrieving the password that I have stored there and use it to hack the license breaking the first security barrier.
At this point I am not considering code obfuscation (eventually I will), so this is an issue.
I know that any solution that stores passwords is a security hazard but there's no way around it!
I considered assembling the password from multiple pieces before really needing it, but at some point the password is complete so a debugger and a well place breakpoint is all that is needed.
What approaches do you guys(and galls), use when you need to store your passwords hard-coded in your app?
Cheers
My personal opinion is the same as GregS above: it is a waste of time. The application will be pirated, no matter how much you try to prevent it. However...
Your best bet is to cut down on casual-piracy.
Consider that you have two classes of users. The normal user and the pirate. The pirate will go to great lengths to crack your application. The normal user just wants to use your application to get something done. You can't do anything about the pirate.
A normal user isn't going to know anything about cracking code ("uh...what's a hex editor?"). If it is easier for this type of person to buy the application than it is to pirate it, then they are more likely to buy it.
It looks like the solutions you have already considered will be effective against the normal user. And that's about all that you can do.
Decide now how much time/effort you want to spend on preventing piracy. If someone is determined, they're probably going to get your application to work anyway.
I know you don't want to hear it, but it's a waste of time, and if your app needs a hardcoded password then that is a flaw.
I don't know that there is any approach to solving this problem that would deter a hacker in any meaningful way. Keeping the secret a secret is one of cryptography's great problems.
An approach I have done in the past was to generate an unique ID during the install, it would get the HDD and MCU's SN and use it in a complex structure, then the user will send this number for our automated system and we reply back with another block of that, the app will now decrypt and compare this data on the fly during the use.
Yes I works but it still have the harded password, we have some layers for protection (ie. there are some techniques that prevents a mid-level hacker to understand our security system).
I would just recommend you to do a very complex system and try to hack it on your own, see if disassembly can lead to an easy path. Add some random calls to random subroutines, make it very alleatory, try to fake the use of registry keys and global variables, turn the hacker life in a hell so he will eventually give up.
If my website uses a POST form for login, what is a quick and easy way to prevent a rogue client from flooding my web server with POST requests trying to brute force crack my user accounts?
PHP/MySQL/Apache.
Preventing brute force cracking is trickier than it may at first seem. The solution will be to combine controls - one single control will not cut the mustard. And remember the goal: you want to slow down a brute force attack to the point where it will either be ineffective, or you can detect it and take action. The second option is generally more effective than than first.
You could use a captcha (this is currently a popular technique) but captchas can often be automatically read, and when they can't be read by a computer, farms of people can be be obtained by paying low waged workers or by using the captcha to protect "free" porn (both techniques have been used).
The advice of others to use a secret value in the form won't really help; an attacker simply has to parse the HTML to find the secret value, and include it in their post. This is pretty simple to automate, so it's not really a good defense. Oh, and if the value turns out to be easily predictable (using a poor or broken PRNG or a bad seed) you're up the creek, again.
Tracking the IP address is okay, but only if you don't support NAT. With NAT, valid users will appear to be duplicates. And remember that attackers can impersonate other systems; a single attack system can use other IP addresses, and even intercept the traffic to that system (ARP poisoning is one good mechanism for this).
You could use a max number of failed timeouts in a given period of time (like 3 within 1 hour). This slows the attacker down, but doesn't necessarily stop them. You might include an automated unlock, but you'll need to do some math, and make sure that the unlock time is actually useful.
Exponential backoff is another useful mechanism. This might be possible to tie to a session (which the attacker doesn't have to return to the server) to the IP address (With breaks with NAT) or to the account (which doesn't account for brute forcing across multiple accounts).
For the other defenses to be useful, you have to have strong passwords. If your passwords are easy to guess (are they in a dictionary? are they short? are they complex?) the attack will succeed. It's a good idea to implement minimum password strength requirements, and an "illegal passwords" dictionary (combined with common character substitutions for that dictionary). Alternatively, you might use a system like OATH, certificate login, or hardware tokens (like RSA's SecurID).
I think it was Burt Kaliski who discussed client puzzles. Basically, you give the client a challenge that's easy for the server, but difficult for the client; the client DoSes itself by wasting its own resources trying to solve the puzzle. The difficulty, here, would be in determining the right complexity for the puzzle. It might, for example, be factoring a large number. Whatever it is, you'd have to assume the most efficient possible algorithm, and you'd have to be able to handle different performance of different browsers on different machines (potentially slow) while slowing down automated attacks outside of browsers (potentially faster than your javascript). Did I mention that you'd have to implement a solution in JavaScript?
But you're still stuck with an attack that works across multiple accounts. I'm not aware of any publicly used controls that work well against this, unless you can track IP addresses.
Then, you'll want to protect usernames. An attacker who doesn't know usernames (requiring a system that doesn't indicate when usernames are valid) will have to learn both the username and the password, instead of easily confirming a username, then just attacking passwords.
And you'll need to be careful that error messages, and server timing don't give away (in)valid passwords, either.
And when you deal with error messages, make sure that password recovery mechanisms don't give anything away. Even in otherwise good systems, password recovery can blow the whole thing.
But, all that said, the attack is ultimately dependant upon the server's performance. You might simply implement a very slow mechanism for authentication (has to be slow for both valid and invalid authns). An online attack is guaranteed to go no faster than the server can process requests.
Then, you need to detect brute force attacks, so your system needs a good audit trail. But you'll need to be careful not to log too many log messages or you'll open up an easy way to dos the server by filling up disk space. Something like syslog's "the previous message has been received 1000 times" message would be good.
Once you're all done designing things, and again when you're done implementing things, you'll want to examine the whole system, and all features of the system, mathematically model it given the current settings and the server's performance and determine the average amount of time it would take an attacker to brute force (a) a single account, and (b) any account (brute forcing across accounts to avoid account-specific controls).
One approach is to keep track of the IP address (or even of the first 3 octets of the IP Address) of each request and to add a significant time in responding to (or even to drop) the requests coming from IPs that have had more than x requests in the last y minutes.
This is ineffective (or less effective) against distributed attacks, but otherwise work quite well, for a relatively simple implentation.
For a stronger proptection, one can also blacklist offending IPs (IPs, or again first 3 octets of IP, which have submitted more than say 6 bad attempts in the last 2 minutes or less) by systematically denying access to such IP for a period of say 15 minutes.
Well, if you know the IP of the source of the login attempt, you could allow it 5 attempts, then make that IP wait through a 5 minute "cool-off" period. If you think 5 minutes is too short, raise it until it's something more suitable (could go as high as 24 hours, or more if you think it's necessary). This might not work as well if they have dozens of coordinated nodes in a botnet.
I'm looking for studies on the security effect of frequent password changes, looking at the security benefits / problems from having a mandatory password change every one or two months or similar.
Does anyone know of any?
Here is a research article on password policy. It mentions the frequency at which people should change their passwords and some other really interesting stuff. Below is an extract.
Some experts say that periodic
password changes will reduce the
damage if an attacker intercepts a
password: once the password is
changed, the attacker is locked out.
This assumes that the recovered
password will not give the attacker
any hints about the victim's current
password. In fact, periodic password
changes tend to encourage people to
design sequences of passwords, like
secret01a, secret01b, secret01c, and
so on.
This allows users to easily choose and
remember a new password when the old
one expires. Such sequences are
usually pretty obvious to an attacker,
so any one of the victim's old
passwords will probably provide the
attacker with a reasonably small
number of passwords to guess at.
The TechReport Do Strong Web Passwords Accomplish Anything? states “changing
the password frequently helps only if the attacker is extremely slow to exploit the harvested credentials.”
In my opinion, forcing people to change their password too often, reduces security because the only way people can remember so many passwords, is to start using stupid passwords like Computer123 or January1 followed by February1 etc...
A better idea is to reduce the frequency and then train people how to create strong passwords.
While not exactly the study you're looking for, it is closely related and might push you in the right direction. I have seen a few studies on the specific topic you're looking for, but can't find the references just yet.
Microsoft Security Guru advice: "Write down your password"
There are a number of bad things that can happen with passwords, and want to mitigate as many as possible without creating new problems. The "change your password" policy is there to mitigate the damage over time that could be caused if your password gets out, by limiting the window of opportunity for an attacker. While not the end-all of security measures, it can sometimes make a huge difference. As a security consultant, I have personally made (this year alone) many tens of thousands of dollars cleaning up messes that could have been avoided entirely if the company had changed important passwords at least yearly.
The danger of changing your password frequently is that you'll pick poor passwords. This makes the situation even worse, because it now allows attacks that would have otherwise not been possible.
The new wisdom, as mentioned in the linked article, is pick (or be assigned) a random password, possibly changed on a regular basis, and write it down somewhere that you keep safe. Obviously you don't leave it with your computer any more than you would leave you keys with your car. The justification is that people are already trained to know how to secure "things" but are naturally poor at securing information. So if you turn the password into a thing you can hold, then you can just secure it the same way you secure your keys. In practice, this works very well, however it tends to make IT departments nervous.
Update, August 2016:
This article: "Frequent password changes are the enemy of security, FTC technologist says" http://arstechnica.com/security/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/?imm_mid=0e6947&cmp=em-webops-na-na-newsltr_security_20160809
has been showing up everywhere this week, including Bruce Scheier's blog, O'Reilly's Security Newsletter, ArsTechnica, Slate, and NewsCombinator, and may be just exactly what you'd asked for earlier this year.
It references:
https://www.cs.unc.edu/~reiter/papers/2010/CCS.pdf
TL;DR summary: Stop expiring/changing passwords. It's a really bad security practice.
I don't know of any studies that exist, but to get you thinking about both sides of the issue, here's a paper against forcing password changes:
Managing network security — Part 10: Change your password
And an instructional site for an educational institute that makes at least a somewhat compelling case (Written by a Ph.D.) for forcing users to change their passwords frequently. These are the main arguments the site gives FOR forcing password changes, after the link to the page:
"Why Do I Have to Change My !#$%#* Password?"
If you're required to change your
password at least every six months,
someone who's hacked your password
and has been accessing your account
without your knowledge will
immediately be shut out once your
password is changed. Some may think
this is an uncommon scenario, but
people commonly sell an old computer
and forget to erase passwords they
may have saved for dialing in or for
accessing their email.
If you change your password at least
every six months, hackers who may be
trying to crack your password using
brute force (as described above)
basically need to start over because
your password may now have been
changed to some pattern they've
already tried and rejected.
Forcing a password change also
discourages users from using the same
password on multiple accounts. (Using
the same password on multiple
accounts is bad because then your
password is only as secure as the
least secure of the systems sharing
that common password, and if your
account does get compromised, the bad
guy suddenly has access not just to
one account, but to multiple
accounts, magnifying the scope of the
problem).
As far as "research" goes, these might not cut it, but seem to be at least a good introduction to both sides of the argument.
It's not a study, but Gene Spafford posted a short article that discusses the reasons why a policy of frequent password changes doesn't make much sense:
http://www.cerias.purdue.edu/site/blog/post/password-change-myths/
Passwords should be changed when you believe that your password may have been or may soon be compromised. Otherwise, it is usually a useless waste of time, and actually a security hazard. See this link:
http://old.news.yahoo.com/s/ytech_wguy/20100413/tc_ytech_wguy/ytech_wguy_tc1590
This is an excellent paper published in an ACM publication (from 2010) that discusses the cost-benefit analysis of security and user expectations.
http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf
It does make the claim that changing passwords is certainly good advice, but it may not be worth the cost to the users since there is so little evidence to support the idea that we are safer with more frequent password changes. It really is such a good article.