tags:

views:

97

answers:

5

While filling out secure forms on bank websites, I have always wondered how they know their application is completely secure. Sure you know you are on SSL, your account "should" be secure, and hopefully the security question, account throttle, timeouts etc. should keep your account safe. But what is the best way to test this? And what determines how "safe" your application is? What if there was a bug in your code somewhere, then it would not matter how many safeguards you have in place.

I recently created a login for a website which will log the user out automatically after 15 mins, will lock their account after 3 failed attempts, contains a security question, and runs on SSL. But I need to know what determines the security of a program.

Thanks for any help!
Metropolis

EDIT

The main question is. "What is the best way to test for PHP security". Is there steps to take to ensure this. Surely there must be.

+1  A: 

But I need to know what determines the security of a program.

This is a very hard question to give a general answer to. It sounds like you have done everything in your power to secure your application. If security is that important to you it may be an idea to hire a company specialized in security audits.

captaintokyo
+7  A: 

There is a standard for security verification of web applications: OWASP ASVS.

It prescribes a checklist of all the processes you must have in place, and all the facts you must have verified before you can claim a certain level of security. I suggest you go read the detailed requirements to know what is involved. An example of an ASVS requirement is "Verify that a positive validation pattern is defined and applied to all input."

The requirements are grouped into 4 levels:

  • Level 1 is appropriate for small low-risk apps
  • Level 2 is appropriate for typical business apps
  • Level 3 is appropriate for high-reliability apps
  • Level 4 is appropriate for life-critical apps

Another possible standard to adhere to is the Microsoft Security Development Lifecycle (SDL). It's the process they use for their own products. The SDL is more process-oriented, and more generic.

Joeri Sebrechts
Thanks for the link. Interesting..
captaintokyo
Great! Thanks Joeri this is exactly what I was looking for.
Metropolis
+3  A: 

There is no way to be 100% sure, believe it or not, banks are actually broken into from time to time, recently here in Denmark a serious vulnerability has been found in the goverment backed "NemID" (Easy ID) where it doesn't log you out even though it tells you it has.

However, to try and nip stuff like that in the butt, try and break it yourself, think like a hacker, its your code, what little quirks and workarounds are there that could possibly let you in.

http://labs.securitycompass.com/index.php/exploit-me/ has a bunch of resources for checking for XSS, sqlinjection etc, also I highly recommend The Web Application Hackers Handbook

Also, if you are very serious about your security, get an external reputed consultant/company to review your code.

...But before all that, please consider this, is what you are protecting important enough to pull out the nukes... or is a breadknife enough?

Kristoffer S Hansen
A: 

You are only talking about the front-end / user-visible security. That´s just one aspect, don´t forget about the back-end security; the server, the database, the php-code, etc.

jeroen
A: 

Although I'm not exactly answering your question, let me just give you some food for thought regarding the "lock their account after 3 failed attempts" practice, which can be easily abused and is a form of denial of service.

Even though this is not a security issue per se but more of a usability issue arising from securing a system, it should be a consideration when thinking about security, and is on my mind these days because I've come across some pretty silly implementations of it recently, especially in e-banking applications:

  • 2 of my banks will lock you out after 3 failed login attempts. You'll notice I don't have a "within X time" constraint, because there isn't any. If you mistype your password today, and you did so a month ago and again 8 months ago, it will lock you out. It does not reset once you log in successfully.

  • Couple this with a policy of forcing you to change your password atleast once a month and requiring strictly 6-digit numeric passwords and you have alot of users being blocked all the time. Atleast they will unblock it after verifying your identity over the phone so you can retry if you believe you know your password.

  • Another one will lock you out after 4 failed login attempts. I'm not sure about a time constraint there because it only happened once to me so far. However, they cannot unlock your account after phone verification, nor in person at the bank itself. The policy is to send you a new password, by mail. Mail, not e-mail. I've been waiting for mine for over a week now.

  • In my case all these happened to me following my actions, but someone could easily annoy me by locking me out if he knows my username, or the general public just by trying random ones.

My point is that automatic lockout is pretty widespread, but it takes effort to make it a deterrent to attackers while keeping it user-friendly to the legitimate users. Perhaps:

  • After 3 failed attempts ask if the user has forgotten his password and offer the support phone number

  • If the failed attempts are too frequent or there's any robotic behaviour (bad UA, instant submit after loading the page), show a captcha along the login form.

  • As the failed attempts continue, increase the time to wait before being allowed a new attempt. For example after 3 failed attempts, require the user to wait 30 seconds before retrying. Another 2 failed, wait 2 minutes.

  • If you are going to lock the account, offer again the phone support number in the same page so a frustrated user will be able to get some help.

Any other ideas?

Fanis