Is my site secure?

[andy89]

On my site I have an CMS. But in order to get to it you must put in a password and username.

The username and password are stored in a database and the password is hashed with md5. When a correct password and username is entered it stores a 'ticket' in a session and that is checked by every page in the admin section before any content is transfered. Else your redirected to the login page.

Is this secure enough?

EDIT: its a php site, that make any difference?

 

[nightelf]

Are you using a shared hosting plan or a virtual/dedicated one? Do you have a SSL certificate?

Someone could sniff the connection between your site and the user and get the Session ID. I read that is more secure when you also record and compare the IP.

Did you build the app, or it was downloaded from Internet?

 

[andy89]

yeah, I built the app.

I'm not sure if I can set up ssl with my host.
An thats a good idea. I might add a check on each page to see if the ip has change, and if it has destroy the session.

 

[stndn]

Just so you know, if your users are on dialup, comparing session to IP address is a little tricky.

When your users reconnect, the IP address might change, and the user is then blocked out and have to login again.

Not that I know of better solution (this has always been problems on many sites). But what we used at our site is to store a random token as a cookie (in addition to the session), which gets regenerated on each login. That way, even if the session is stolen, the "thief" might not be able to get in if the random cookie is not present.

(the cookie is stored in database to match with the current user's session ID)


Btw, if you're on shared hosting, your session information might not be secure as they are stored in shared /tmp. You might want to look at storing session information in database if it's a big concern.

All in all, it depends on how much security you want to implement on your site. Just note that higher security usually translates to more troubles for users.


-stndn.

 

[gekko513]

stndn has a good point. If it's possible in any way to predict the ticket and access the site that way, you're not secure.

 

[jeremy.king]

I know its been mentioned, but do realize if your login form is posting to a non-SSL login page, then the username/pass is being sent in plain text and can easily be sniffed. This is a little more serious than hijacking cookies.

 

[mnkeybsness]

I'd just like to interrupt and ask:

Why are you so concerned? Do you actually have readon to believe someone would want to hack your site?

A great resource for learning about securing PHP applications and functions is the Secure PHP Wiki.

 

[NoNameBrand]

Getting SSL setup is probably your #1 concern.

Are you worried about brute force password attacks (once they're not able to sniff)?

An intranet web app we have at work is going to be hardened (by yours truely - I wrote everything else too) before we allow access from outside our intranet.

My plan is to put a Turing test on the login screen, similar to Eric Meyer's Wordpress Gatekeeper plugin "http://meyerweb.com/eric/tools/wordpress/wp-gatekeeper.html". This avoids idiotic (and easily breakable) captcha systems. Failing to answer the question correctly results in a failed login attempt, with no indication of which of the three fields were wrong. (username, password, turing).

Also, each account will only be enabled for remote login if it passes a dictionary attack, which will be carried out upon any password reset.


Other security stuff:

PHP specific: Make sure register_globals is set to OFF, if you're using a version of PHP where it's not removed entirely (it's removed in PHP 6).

Having a session time out wouldn't be a bad idea. You can store POST/GET data server side for when users re-authenticate so they don't lose anything from the time out.

To prevent reloading of pages with login info, you can output a random number with each (login) form, and store the most recently sent one on the server side, if they don't match on submit, no login. This also works for preventing people from resending data that you don't want entered twice (or more!) like an order, though you can possibly just use a counter rather than a random number.