PHP Security

[johnrb87]

Hi everyone

 

I'm kinda new to PHP and have a couple of questions;

 

1: How secure is PHP, is it very hackable? Are there things you recommend to make it more secure?

 

2: I am building a little employee system for staff at a friends company and they can view personal information when they login, as well as ordering stuff with online payment through WorldPay.

 

What is therefore the best and most secure way of handling passwords, logins, data, insert statements etc.

 

I basically want to make it as secure as possible and hopefully learn some new skills

 

Any tips or help would be great

 

Thanks

[Psycho]

PHP is as secure as YOU make it. The answers to your questions could (nad have) fill entire books. Trying to answer them in a forum post cannot be done in an adequate manner. There are plenty of articles out there on different aspects of security (file locaitons, database, encryption, etc.). You will need to do research on each type of security to decide how best to approach it.

 

however, if you have questions about a specific "piece" then by all means aska  question here to get answers/opinions.

[coupe-r]

For passwords, you have 2 different ways.

 

1. 1 way hash / encrypt - $password = md5(sha1(sha1(md5($password))));

 

This will allow you to mash up the password pretty good, but if the user forgets the PW, it needs to be reset to a random string.

 

2. 2 way hash / encrypt - Tutorial in this forum

 

This will encrypt the password, but will allow you to decrypt it as well.

 

$password = encrypt($password);

$password = decrypt($password);

 

Lots and lots of stuff out there.  With payments, you are also talking SSL and/or HTTPs.

[rwwd]

1. 1 way hash / encrypt - $password = md5(sha1(sha1(md5($password))));

 

What a waste of CPU & parser power - md5() was hacked a while back, google it to see. I will advocate the use of the hash() function, just use hash_algos(); to see what is available, then use the desired algorithm in the function:-

hash('SHA512', $password);

 

This is a little more secure, but more importantly, less load on the parser..

 

Not picking fault AT ALL, just making you aware of alternatives...

 

@johnrb87: I echo mjdamato's sentiment, the answer to your question will come from experimentation and research from the internet, lot's of people have lot's of different ways of doing pretty much the same thing, just remember, you can only make your application as secure as you know how to, even now I stumble across functions which I think, Ah! I can replace this with that and make this quicker - it's all down to learning and knowledge.

 

Don't forget you can always post on here, and the good chaps will assist/help/advise with your code.

 

Above all have fun!

 

Rw

[Psycho]

md5() was hacked a while back, google it to see.

 

md5() is more than adequate for hashing a password. Although you should use a salt just as you should for any hashing algorithm. The "flaw" in the md5() algorithm is around the ability to knowingly create a collision. FOr the purposes of a password (which is made up of a limited range of characters and from a specific list of characters) a collission would be nearly impossible. Even if it was possible the "hacker" would have to know the md5() hash which they were trying to duplicate. The purpose of hashing a password is in protecting the password. Creating a collision does not expose the password. Plus, to create a collision, the hacker would need access to the hashes (i.e. the database). But, then there is no purpose to tryng to create a collision since the hacker already has access to all the data anyway (except the passwords which are hashed).

 

The threat is a user who gets a copy of your database and then tries to obtain users's actual passwords. That is why you use a salt so the user cannot simply use a rainbow table. That is also why you should never use a simple word as your password since malicious users will typically start with a dictionary attack.

[rwwd]

^^^

 

I agree with that, I was just suggesting that hash('', $input) seems to be the preferred method of creating a hash value nowadays, I was criticised recently for having the 'lesser' effective md5() in use for storing sensitive data on a server, this is why I changed to hash()...

 

The only thing to remember is to check to see how long the chosen algorithm (returned value) is so that you can set the length value in the DB so that when you store it you don't get the end cut off, I had to fix that a couple of weeks back on a chap's code.. poor chap! We all have days like that!

 

Rw

[merylvingien]

I recently had someone asked about password storage and retrieval

The way i have done things on my site, not one worth hacking by the way!

anyway, all passwords are hashed using md5, and also a unique hashed code is also stored in the database.

So from the time the user first enters thier password on registration, apart from login, we are always dealing with a hashed password.

If they forget thier password, obviously we cannot decrypt thier password, so they enter thier email address into a password reset box

This sends them a email with a link, with the unique code as part of the link.

Using the get method, you retrieve the code, check against the code in the database, if it matches the user can then reset thier password.

A new unique code is then generated and updated in the database, so its a one shot code. Once used cannot be used again!

 

I have run into issues using sessions, cross contimination of session id's etc, be extra carefull when setting session id's and where you use them....

[johnrb87]

Thanks for the replies everyone, I know there are plenty of reads out there on these subjects, but I kind of wanted to hear what people on hear thought.

 

So thanks so far, i'll keep an eye out for anymore helps

 

Cheers

[johnrb87]

So are SESSIONS a good way to secure data still? Or can SESSIONS be manipulated and taken advantage of?

[meltingpoint]

SESSIONS are good- but it has to be part of the security solution, not the total solution. 

Yes- they can be hijacked and manipulated (if you leave your self vulnerable to that exploit)

SESSIONS are better for passing user permissions/info throughout the site than by the $_GET method.  With SESSIONS I would;

 

1- Once a user is signed in- store the original IP address as a SESSION variable and check that on any secure page to make sure someone has not hi-jacked the session and is attempting to access the page from another location.

2- Never store the users password as a SESSION variable. 

3- Create a time out scenario.  Create a start time() on each page and check that on each subsequent page to see if say 30 minutes has passed with no activity.  If the time between viewing pages is greater than 30 minutes- re-direct to a log-out page.

 

Depending on your requirements- these are some security measures.  There are many more that you can tailor to your needs. 

 

Hope that helps------------

[johnrb87]

thanks for the extra tips, anything else anyone has to input would be a great help

[Psycho]

3- Create a time out scenario.  Create a start time() on each page and check that on each subsequent page to see if say 30 minutes has passed with no activity.  If the time between viewing pages is greater than 30 minutes- re-direct to a log-out page.

 

Seems like a lot of work when you could simply set the session timeout period to whatever value you wanted. Then just ckeck if there is an active session on each page load.