Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Web & MYSQL - User Auth & Security


  • Please log in to reply
22 replies to this topic

#1 Nate15329

Nate15329

  • Members
  • 92 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:WI, USA
  • Local time:08:11 PM

Posted 21 April 2012 - 01:52 PM

Currently, I am developing a Website that uses a mysql databases. So far from searching the net, i've only found very insecure ways of connecting to the database(by using very few powerful users). What would be better?


Method 1(i think is very insecure):
Specialized General users with special permissions for certain tasks for after authentication after website login by read only general user of the table.

or

Method 2:
Login -> Checks Website Database users Table (using a read only user for that table for mysql connection) -> if good -> save credentials as session variables -> log into the database with credentials saved.

or

Method 3:
Login -> Attempts to login to mysql -> connects into database server using user credentials -> if success -> saves crediatials for login in a session variable

or

Something else...

Of course, there will be more security as well that wasn't mentioned. Also, It would be better to have more control of who's accessing the database for remote management, so i think Method 2 or 3 would be best; probably method 3 since it requires less steps involved. This may belong into the programming forum as well, but it's more for secure website & sql authentication at the same time. Thanks.

BC AdBot (Login to Remove)

 


#2 cryptodan

cryptodan

    Bleepin Madman


  • Members
  • 21,868 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Catonsville, Md
  • Local time:02:11 AM

Posted 21 April 2012 - 02:28 PM

When i hear the terms "remote management" I think of an outside computer not a web application making a direct connection to mysql from the outside. Is this what you mean?

#3 groovicus

groovicus

  • Security Colleague
  • 9,963 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Centerville, SD
  • Local time:08:11 PM

Posted 21 April 2012 - 04:08 PM

And what do you mean by 'save credentials'? What credentials specifically?

#4 Nate15329

Nate15329
  • Topic Starter

  • Members
  • 92 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:WI, USA
  • Local time:08:11 PM

Posted 21 April 2012 - 06:02 PM

And what do you mean by 'save credentials'? What credentials specifically?


The user sends username & password(aka credentials). since it would be using PHP, I would have to save the username and password into secure php session variables(aka temporary saved credentials) for the web server to connect to the databases under the user's login information to securely limit of what they can and can't do in the databases and tables. Most people just give the web server all connections to the database with very high privileges without regard due to having the database and web server in the same network or same machine(horrible idea for the security side).

When i hear the terms "remote management" I think of an outside computer not a web application making a direct connection to mysql from the outside. Is this what you mean?


No, the client computers will not be able to connect remotely into the database, only the administrator. The client computers will be connecting by web browser to the web server/s which connects to the database server/s.

#5 groovicus

groovicus

  • Security Colleague
  • 9,963 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Centerville, SD
  • Local time:08:11 PM

Posted 21 April 2012 - 09:26 PM

No, you shouldn't save any kind of credentials at all. If the use and login are valid, you send a session id back to the user, and use the session id to validate the session. In the server side, if the login is valid, then you should create a role or group for that user, and store that in the session.

Of course, all of that is moot if you are not using ssl to do the login.

#6 Nate15329

Nate15329
  • Topic Starter

  • Members
  • 92 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:WI, USA
  • Local time:08:11 PM

Posted 22 April 2012 - 02:15 PM

No, you shouldn't save any kind of credentials at all. If the use and login are valid, you send a session id back to the user, and use the session id to validate the session. In the server side, if the login is valid, then you should create a role or group for that user, and store that in the session.

Of course, all of that is moot if you are not using ssl to do the login.


Ok....let me put it into a better perspective of Method 2/3

Login:
User sends username & password via https(whole site is this by the way) ->(server side) php login (sends back regenerated session id to user) page which checks if login information is correct(either by attempting php->mysql ssl login or by a read only user/role to a user authentication table(which allows everyone can read!!!)) ->(server side) if checks out, saves the username and password in the php session variables (sends regenerated session id to user) for future mysql login/access for their account;(server side) if doesn't checks out, php session destroy with logging attempts.

Logout:
(Server side) PHP session destroy (which knocks out the saved credentials in session variables)

Now your way is to have a single user acting as a groups/roles which are hard coded into the php pages with login information (username & password), which can be easier to be exploited. Also it is harder of finding out what user is "hacking"/"overloading" the database with billions of database queries going at once with few group/role accounts. I will be setting up group content per group for website display, im more worried about the database being compromised from group users/roles such as those if i use global group/role accounts in the database system.

Also for every site a user logs in to, should be at least https/ssl for every piece of content loaded. Also, I was told databases are an entire Operating System in themselves and are to me when i started reading about them. how would you secure your operating system in a business world...one global account for everybody or one account per user? Cause one global account or even general accounts per user type are far less secure than one account per person and that's what you're telling me to use general accounts per user type for database access from your reply. Plus, for future development, it would be nice to have it setup for applications to interact with the databases as well without major changes to database security side of things.

#7 cryptodan

cryptodan

    Bleepin Madman


  • Members
  • 21,868 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Catonsville, Md
  • Local time:02:11 AM

Posted 22 April 2012 - 02:21 PM

Each role would be defined by the grant permissions within the MySQL Database not by the PHP. PHP is just scripting, and does not deal with permissions or anything like that. I think you are confused with how PHP and MySQL interact with each other.

I would recommend you read up on MySQL and PHP from http://www.mysql.com and http://www.php.net to get a better understanding of how PHP and MySQL works.

#8 Nate15329

Nate15329
  • Topic Starter

  • Members
  • 92 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:WI, USA
  • Local time:08:11 PM

Posted 22 April 2012 - 04:28 PM

Each role would be defined by the grant permissions within the MySQL Database not by the PHP. PHP is just scripting, and does not deal with permissions or anything like that. I think you are confused with how PHP and MySQL interact with each other.

I would recommend you read up on MySQL and PHP from http://www.mysql.com and http://www.php.net to get a better understanding of how PHP and MySQL works.


I know that each role(SELECT, INSERT, DROP, ALTER, CREATE, etc) is defined by the grant permissions within the mysql database...PHP logs into the database with a user account( that has certain roles(within mysql) that allows the user to do what the user can do) & does what it is scripted to do. However, so far everyone says to use one/few accounts for these connections since its a website(that has a specific global role in the database/s) and not bothering with the secure way of logging into a database server with individual accounts.

Also, from the administrative side for monitoring, they need to know who's connected, not just basic accounts like if im a student on a school website; i use a global account called student and every student uses the same account to connect to the database without knowing since its php.

So, would you rather have MYSQL do the permissions per private user account or have the website look at a table for the website to do the permissions(since mysql group accounts for the site would be used & hard coded into php scripting)?


I would rather have mysql do the permissions per private user account and just want to know the securest way to do it mainly(besides lowest access possible & ssl connections). If the webserver/s gets hacked, they won't get any passwords from the php code or be able to find out how to connect to the user table of the database for the site that contains usernames and passwords(hashed) if I do it by method 3 & less likely they would get farther than that.

#9 cryptodan

cryptodan

    Bleepin Madman


  • Members
  • 21,868 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Catonsville, Md
  • Local time:02:11 AM

Posted 22 April 2012 - 05:45 PM

Well if they have hacked your web servers and have raw access to the server, then you aren't really providing a secure method to connect to the DB. Once they are in, there is nothing you can do to prevent the access to the database. The PHP Code will be easily readable by anyone with a text editor and by any account that has read access to the files. So one account should be used for administrative purposes, and only one IP should be allowed to login to the MySQL DB. After that user accounts should be set up via a MySQL Database Table and permissions setup via that method with no one else being able to login.

#10 Nate15329

Nate15329
  • Topic Starter

  • Members
  • 92 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:WI, USA
  • Local time:08:11 PM

Posted 23 April 2012 - 01:21 AM

Well if they have hacked your web servers and have raw access to the server, then you aren't really providing a secure method to connect to the DB. Once they are in, there is nothing you can do to prevent the access to the database. The PHP Code will be easily readable by anyone with a text editor and by any account that has read access to the files. So one account should be used for administrative purposes, and only one IP should be allowed to login to the MySQL DB. After that user accounts should be set up via a MySQL Database Table and permissions setup via that method with no one else being able to login.


Exactly on about the php code being in plain text which is also why the database php credential variables should be the user's private account credentials (dynamically per session as variables(of course not in plain text), so there is no credentials even within the php plain text code for hackers to use(which prevents access to the database)...also the database is on a completely different server/s of its own(if you were thinking raw database file reading) that can only be accessed by the web server at the moment.

#11 cryptodan

cryptodan

    Bleepin Madman


  • Members
  • 21,868 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Catonsville, Md
  • Local time:02:11 AM

Posted 23 April 2012 - 04:35 AM

the database could still be accessed, as there would still need to be a config file to store the main username and password to connect to the database even if it was on another server. Without that configuration file there would be no connection to the server what so ever.

#12 Nate15329

Nate15329
  • Topic Starter

  • Members
  • 92 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:WI, USA
  • Local time:08:11 PM

Posted 23 April 2012 - 12:31 PM

the database could still be accessed, as there would still need to be a config file to store the main username and password to connect to the database even if it was on another server. Without that configuration file there would be no connection to the server what so ever.


True, if you were accessing via ssh/console(only few secured accounts has access these ways and they(including the services) are locked down) since the database is stored basically in a single large file in directory. But PHP connects to the database via mysql port, which requires mysql user authentication for the connection, which reads the mysql built-in user table like shadow & SAM files. So authentication that way is way more secure...

This is what I see overall:

Your(& others) way quick example (after user is logged in):

<?php
$con = mysql_connect("localhost","user_read","password"); //Note: not the user that is actually logged into the website, but a general account for a certain purpose with password exposed & everyone in a group defined can use it
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_close($con);
?>

Features:
uses single/few usernames built into mysql builtin user table for connections
must find user from a custom table for permissions that only apply to php source code when executed.
harder to secure future applications source code(even if its closed source, assembly code can be read)
easier to use these group accounts against the system through bugs in the source code
harder to see what user is doing what & what account is compromised.


My way quick example(after user has successfully logged in):

<?php
$user=_SESSION['username'];
$pass=_SESSION['password']; //Note: this won't be in plain text
$con=mysql_connect("172.17.1.2",$user,$pass); //note:database access is currently only through private network for now.
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_close($con);
?>

Features:
Secured php code for mysql database access(cause no login information is stored in files).
Easier for future development for applications.
Each private account has specific roles/access per table per database upon registration.(permissions do not need to be looked up in a custom table)
Easier to secure mysql connections with limits per user account through mysql config file.
Easier to filter users for what is going wrong.


Edited by Nate15329, 23 April 2012 - 12:33 PM.


#13 cryptodan

cryptodan

    Bleepin Madman


  • Members
  • 21,868 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Catonsville, Md
  • Local time:02:11 AM

Posted 23 April 2012 - 12:49 PM

$pass=_SESSION['password']; //Note: this won't be in plain text


Even if not plain text or encrypted once the server is hacked, then all they need to do is grab the encrypted password and run it through cracking software to gain access to your databases.

#14 Nate15329

Nate15329
  • Topic Starter

  • Members
  • 92 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:WI, USA
  • Local time:08:11 PM

Posted 23 April 2012 - 04:30 PM


$pass=_SESSION['password']; //Note: this won't be in plain text


Even if not plain text or encrypted once the server is hacked, then all they need to do is grab the encrypted password and run it through cracking software to gain access to your databases.


True, but also depending on the hashing/encryption, with salt or not, how many times its been hashed/encrypted, and the length of the persons password(which would be at least certain amount of characters), changes how long to compile for the cracking software to even make a match, let alone get it in a life time. Making it useless to bruteforce or even use pre-made tables. especially with software monitoring users attempting to login and denys/blocks them if they fail a certain amount of failed passwords & non-existent usernames.

Also, I wonder if php session variables can be only stored inside memory than in a temporary file on the server, especially for something like this as well and reducing I/O usage, while having some session variables saved via file if they don't need to be secured. this would make it even rarer for hackers to even attempt it without using man-in-the-middle or side jacking(still have to think how to secure this better).

#15 cryptodan

cryptodan

    Bleepin Madman


  • Members
  • 21,868 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Catonsville, Md
  • Local time:02:11 AM

Posted 23 April 2012 - 04:34 PM

Also to take into deep consideration, the only way to prevent hackers from even gaining access to your database is by sanitizing the SQL Queries. Once they have hacked your web server you are already compromised and any internal security measures you take can be negated.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users