Page 1 of 1

Insecure (database) admin login?

Posted: Mon Feb 26, 2007 11:21 am
by jayshields
Hi peeps.

Never really come across this idea before, so I presume it's because it's really insecure, but I can't see why. Basically, it gets an admin password from the user, and tried to log into the admin database user with it, if it works, then great, you're logged in, if it doesn't obviously you're not going to be logged in.

Code: Select all

<?php
session_start();

if (isset($_POST['submit'])) { //If the user is trying to login
	//Escape their password submission
	$password = stripslashes(trim($_POST['password']));

	//Attempt admin connection
	if($link = @mysql_connect('localhost', 'admin', $password)) {
		//If successful
		$_SESSION['logged'] = TRUE;
		$success = TRUE;
    mysql_close($link);
	} else {
		//If unsuccessful
		$error = TRUE;
	}
}

//Show the success message if there is one
if(isset($success)) echo '<p class="success">You are now logged in as admin.</p>';

if(!isset($_SESSION['logged'])) {
	//Show the error message if there is one
	if(isset($error)) echo '<p class="error">Password incorrect.</p>';

	//Show the form
	echo '<form action="#" method="post">
    Password: <input type="password" name="password" size="20" maxlength="50" class="input" /> <input type="submit" name="submit" value="Submit" class="submit" />
		</table>
	</form>';
}
?>
Well, that's the bare bones of my script.

Two ways I've used in the past are:
Checking the entered password against the correct password (unencoded) in a .txt file on the server
With this one, the password is in plain text in the server, but CHMOD'd so Joe Bloggs can't guess the file location and see the password. If the password matches the user is logged in as admin, and then on the administration pages an admin database connect file is included which logs into the database as the admin (allowing SELECT/UPDATE/DELETE).

Checking the entered password against the correct password (hashed) in the database (logged in as the user)
This one is more common, but it defeats the object for me, because what's the point in having a database user for the administration purposes and a database user for the everyday uses (SELECT'ing) if the admin password is stored in the user's database user?

Anyway, obviously I'm missing something because this seems a no-brainer.

Inform me!

Posted: Mon Feb 26, 2007 1:02 pm
by feyd
Aside from various issues like blindly using stripslashes(), the only thing I would recommend is storing a hashed (probably salted in some fashion) password for the file system variant.

I prefer hashed in the database. Less problems can arise from my experience.

Posted: Mon Feb 26, 2007 1:08 pm
by jayshields
feyd wrote:Aside from various issues like blindly using stripslashes()
What do you mean by blindly using it? That the password could actually contain slashes and I'll be stripping them?
feyd wrote:I prefer hashed in the database.
A stored password to gain access to the admin section of the website or a stored password which is the password for a more powerful database user?

Posted: Mon Feb 26, 2007 1:18 pm
by feyd
jayshields wrote:What do you mean by blindly using it? That the password could actually contain slashes and I'll be stripping them?
You don't have logic that checks to see if your code should actually strip slashes. That's blindly performing something. Magic quotes are not always on.
jayshields wrote:A stored password to gain access to the admin section of the website or a stored password which is the password for a more powerful database user?
Either, although I typically would simply give the normal user the specific rights they will need for all purposes regarding that database/table, nothing more.

If you want to log into the database with root level access, don't store the password anywhere on the server. Just allow the database reject the connection.

Posted: Mon Feb 26, 2007 1:26 pm
by jayshields
Ok, point taken. So, if I checked for magic quotes prior to using stripslashes(), which I should know better about anyway and wasn't thinking, what's to fault my method of logging into an admin section of a website? Bearing in mind I could implement some sort of log in check to make sure the user doesn't brute force the database password.

Posted: Mon Feb 26, 2007 1:36 pm
by feyd
I don't see a need for root level access via a website. As I already said, the standard user I set up has all the privileges they will need, administrative or not.

You could also switch to a model whereby the standard user has no ability to delete records at all, but simply flag them as deleted. Later you can have a maintenance script log in to do the garbage collection if need be.

Posted: Mon Feb 26, 2007 1:42 pm
by jayshields
I don't mean root level access. I don't know whether this is the norm but when I'm creating database driven websites I usually create 2 database users for it. One with only SELECT/INSERT permission (f.e. viewing news, viewing comments, posting comments), and one with SELECT/INSERT/UPDATE/DELETE permission (f.e. as before but with edit/delete features). Unless the user is logged into the admin panel the former database user is used.

That second point is a good idea, I've not thought much about that before.

Posted: Mon Feb 26, 2007 1:57 pm
by feyd
I much prefer the second method I mentioned because even if the database user's password is found, it can't do major harm (excluding updating all sorts of things.) .. but that's what backups are for. ;)

Re: Insecure (database) admin login?

Posted: Tue Feb 27, 2007 5:53 am
by Mordred
jayshields wrote://Escape their password submission
$password = stripslashes(trim($_POST['password']));
Old coders' saying:
If the code and comment disagree, they are probably both wrong.
Quite so in this case.

Code: Select all

$_SESSION['logged'] = TRUE; 
$success = TRUE; 
(snip)
                //If unsuccessful 
                $error = TRUE;
So you have THREE different variables in a span of 6 lines which are used to tell if the login was successful or not?


Using the MySQL user system as a webapp level login checking and rights management is not wise nor practical. All transactions between app and mysql server should remain private and well hidden between the two. What would you do if you want to have 10000 users, create 10000 MySQL users? And what if your hosting only allows 2 DB users?

Posted: Tue Feb 27, 2007 8:34 am
by jayshields
I'm clearly digging myself into a hole here.

To answer your first question, I knocked that up in about 5 minutes, and it is in no way is it final or optimized to perfection. I wrote it to show an example of a database login system, not to demonstrate my coding ability or to try and break a world record for minimilistic variable usage.
Mordred wrote:Using the MySQL user system as a webapp level login checking and rights management is not wise nor practical.
This is basically what my post is trying to get at, why is it not wise or practical (taking into account there is only 2 database users like I outlined in a previous post)?

Why would you need 10000 database users? There's only so many combinations of permissions you can set, and I can't see why you'd need more than an administration user and an everyday surfing user.

Posted: Tue Feb 27, 2007 8:47 am
by Mordred
Ah, I've misunderstood the question then.

The point is that you only need one DB user, you just use it differently depending on the rights of the application user.
Which also means that you need another login system to authenticate and authorise the app user.

Those two are only loosely related, you need both systems for a properly functioning web site.

A third, again loosely related problem is how you store credentials for DB and app login.

You seem to be mixing all those in your sample and question and this is maybe why our answers sound confusing. Is it getting clearer or just more confusing? I don't know what to explain further, it would help if your questions are directed separately at those three directions (DB login, app login, credential storage), so we can clear them one at a time, instead of trying to do so simultaneously.

Posted: Tue Feb 27, 2007 11:05 am
by jayshields
Yeah, you're right. I think I am getting at a number of different things without knowing it, but they all form part of the question. I probably should've given more insight as to where I am using this; it's for a website which doesn't allow user login, just admin login.

Anyways, you've both sort of answered my original question by not actually presenting me with any massive security flaws in this login method, so I'm going to go ahead and use it.

On a side note, I will probably be posting a link to the said website in a few days/weeks when I'm done with it. So you can critique it :) Although (obviously) you won't be able to critique my admin login system (besides the fact that it's hidden in the UI!).

Thanks for the help.