Thing is I have a database, passwords are md5 hashed
However if they access the database, do they gain access to just the table or the whole database?
My question really is, if I put the usernames and passwords in one table and all the other stuff in another then cross reference them, is that assisting security or a complete waste of time?
I know nothing about hacking
__________________
<DmncAtrny> I will write on a huge cement block "BY ACCEPTING THIS BRICK THROUGH YOUR WINDOW, YOU ACCEPT IT AS IS AND AGREE TO MY DISCLAIMER OF ALL WARRANTIES, EXPRESS OR IMPLIED, AS WELL AS DISCLAIMERS OF ALL LIABILITY, DIRECT, INDIRECT, CONSEQUENTIAL OR INCIDENTAL, THAT MAY ARISE FROM THE INSTALLATION OF THIS BRICK INTO YOUR BUILDING."
<DmncAtrny> And then hurl it through the window of a Sony officer
<DmncAtrny> and run like hell
I put the usernames and passwords in one table and all the other stuff in another then cross reference them, is that assisting security or a complete waste of time?
I think it's a waste of time. But if you want to separate some info for security reasons I would split the usernames and passwords into different tables.
It makes no difference really. If a hacker can get into your database then they've got access to anything they want regardless of whether or not its in seperate tables.
Personally, I use different tables to hold different data types. In this case I have a table for user accounts / passwords / names / emails and then everything else in different tables.
//Please don't use this for your form processing:
if (isset($_POST['submit']))
//Internet explorer has a bug and does not always send the submit value.
The best way to structure the database is to start with it fully normalized and undo only those normalizations needed for efficiency when reading data. Security is not a reason for changing that.
The only split that could even potentially make a difference for security is to keep the database on a separate server from the web site although even that wouldn't make a difference if the security breach were via remote access instead of locally.
There's not even any point in encrypting the data in the database as with the exception of the passwords (which are hashed rather than encrypted) everything needs to be able to be converted back into its unencrypted value and so anyone gaining access to the server would also gain access to the decryption routines.
If you are just using md5 hashes for passwords then that is the biggest weakness in your security since rainbow tables exist to convert all MD5 hashes into values that will work as the password. At the very least you need to include a salt value that gets added to the password before it is hashed so that the person needs a rainbow table for that salt value in order to break in. Better would be to use a more secure hash such as SHA256.
Thanks guys and hi tangoforce
The way I see it, theres 2 ways to gain access to the site
hacking the server itself, or gaining access through the website
for instance if they hack the server they have access to the whole database and the files on the server I get that
What I mean is by say MYSQL injection, when people access the tables in a site through cracks in the site itself
But I know nothing about this kind of thing or enough about security, I'm sanitizing everything before it goes in the tables
If I used MYSQL injection to access the tables on your site, do I gain access to every table?
For instance I have credits, which you pay for, If I put them on the exact same row as the password, and someone accessed that table, they could presumably just increase a persons credits aswell? or view personal details
So my idea was to split the personal details from the password
I appreciate theres nothing I can do about them hacking the site through the server software, thats beyond my control and in the control of my host
I'm talking about whats within my control to limit (if that makes any sense)
__________________
<DmncAtrny> I will write on a huge cement block "BY ACCEPTING THIS BRICK THROUGH YOUR WINDOW, YOU ACCEPT IT AS IS AND AGREE TO MY DISCLAIMER OF ALL WARRANTIES, EXPRESS OR IMPLIED, AS WELL AS DISCLAIMERS OF ALL LIABILITY, DIRECT, INDIRECT, CONSEQUENTIAL OR INCIDENTAL, THAT MAY ARISE FROM THE INSTALLATION OF THIS BRICK INTO YOUR BUILDING."
<DmncAtrny> And then hurl it through the window of a Sony officer
<DmncAtrny> and run like hell
__________________
<DmncAtrny> I will write on a huge cement block "BY ACCEPTING THIS BRICK THROUGH YOUR WINDOW, YOU ACCEPT IT AS IS AND AGREE TO MY DISCLAIMER OF ALL WARRANTIES, EXPRESS OR IMPLIED, AS WELL AS DISCLAIMERS OF ALL LIABILITY, DIRECT, INDIRECT, CONSEQUENTIAL OR INCIDENTAL, THAT MAY ARISE FROM THE INSTALLATION OF THIS BRICK INTO YOUR BUILDING."
<DmncAtrny> And then hurl it through the window of a Sony officer
<DmncAtrny> and run like hell
It makes no difference really. If a hacker can get into your database then they've got access to anything they want regardless of whether or not its in seperate tables.
What that means is that however a hacker gets into your database, once they are in, they have full access to the database that was selected using mysql_select_db(). They can run whatever commands they wish, access any tables they want, delete any data they want, update any data they want etc according to the scripts mysql user permissions. That of course is theoretical - I read a somewhere that mysql 5 did away with the ability to run mutliple sql statements in one call to mysql_query however I'm not sure I'd trust that too much as a last line of defence.
For scripts that do not update a DB I would use a mysql user that has only read access and no update/insert permission.
//Please don't use this for your form processing:
if (isset($_POST['submit']))
//Internet explorer has a bug and does not always send the submit value.
Before you post, read our: 
