...

View Full Version : anyone know much about hacking?



nomanic
07-17-2012, 01:07 AM
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

Len Whistler
07-17-2012, 01:43 AM
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.



---

tangoforce
07-17-2012, 02:03 AM
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.

felgall
07-17-2012, 04:26 AM
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.

nomanic
07-17-2012, 10:49 AM
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)

nomanic
07-18-2012, 03:39 PM
bumping anyone?

tangoforce
07-18-2012, 06:47 PM
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.



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum