I'd like to make a very secure site

[eluser]RS71[/eluser]
Hello

I'd like to make a very secure site since I will be dealing with people's personal data. Could you guys give me some tips? (Anything from password hashing, to server security, to sessions, to forms, etc)

Thanks in advance.

[eluser]Charles Garrison[/eluser]
- There are session classes that have been built for CI that replace the native one - I would recommend looking into these. Ex: http://codeigniter.com/wiki/OB_Session/

- SH1 is considered more secure than MD5 for hashing.

- Make sure you run all data coming in through the input class (reference link below). This will help protect you against XSS attacks by properly escaping your data.

- Make sure you set all the proper values in config.php - in particular, you will probably want to set $config['sess_encrypt_cookie'] to TRUE

It's a good idea to read these parts of the documentation very throughly:
- http://ellislab.com/codeigniter/user-gui...input.html
- http://ellislab.com/codeigniter/user-gui...urity.html

[eluser]Gordaen[/eluser]
I think Charles hit the primary points. If someone were to gain access to your database, s/he should not be able to do much with it. That means passwords would obviously be encrypted with a salt, but you also want to consider any other information that should be confidential. Be sure to set the right users with the right permissions (web server, php process, mysql user, etc.). There are all kinds of general security articles online, so be ready to read

[eluser]RS71[/eluser]
Thanks for the tips.

Should I be encrypting data that could be used to identify a person? Like name, email and telephone? I'd need to constantly view/decrypt that information, should I still do it? Would I have a huge performance impact from all of the decrypting?

Charles, I've read the wiki on OB Session but how exactly does it differ from the native library?

[eluser]Gordaen[/eluser]
Unless you're keeping a list of terrorists names, you don't need to worry about encrypting that Names, addresses, phone numbers, etc. are all things that can be found easily enough in phone books, public records, etc., so you don't need to encrypt them in most cases.

[eluser]TheFuzzy0ne[/eluser]
In most cases, the number and name going across the card is useless without the expiry date and the security code at the back, which I think it would be wise to have the user enter each time to confirm they are in possession of the card. Obviously, you need to be careful here, as the browser will probably store this information.

[eluser]Wuushu[/eluser]
- Hash (MD5/SHA1) passwords with a "salt", makes rainbow lookups harder
- Filter all input through xss_clean
- all actions that modifies data should be through POSTs, and those POSTs should have CSRF-token unique for each user and/or session
- Have the session lib use IP as part of the matching, makes it harder to steal a session

just a few ontop of my head

[eluser]Gordaen[/eluser]
It's worth noting that the security code isn't necessary for transactions unless the merchant requires it. Also, American Express cards have the code on the front (and it's four digits).

I generally don't have the IP address used as part of the matching, because many people's networks are behind routers and switch between them for load balancing.