i've never had cause to deal with encrypting passwords in a database before...what's best practice? is using just the md5() function good enough? i'm not dealing with anything sensitive, really, but i obviously don't want to store passwords in plain text

3/30/2009 10:42:51 AM

MD5 is not encryption and is (IIRC) reversable.

You want the crypt() function at a minimum.

3/30/2009 1:11:13 PM

i was under the impression that MD5 was NOT reversible, but i could be wrong as i just now started looking to this...i didn't quite mean to imply that MD5 was "encryption," but i did anyway

is there any reason that MD5 + a salt wouldn't be enough? my understanding (which could, of course, be wrong) is that unless your passwords are dictionary-type words, MD5 and a salt should be plenty secure...this site/article confirms this belief, but i don't know

http://phpsec.org/articles/2005/password-hashing.html

3/30/2009 1:33:58 PM

MD5 isnt really reversable. You cant run the algorithm in reverse to get the unhashed value, but if you have a table of common words -> hashes you can pretty quickly find easy targets. Salt+hash kind of fixes that since its almost impossible to guess every word + every salt. You might want to go with SHA1 instead of MD5 since its less collision prone.

However, if php has its own crypto libraries for doing this why not just use them?

3/30/2009 1:48:42 PM

Or be not gay and use LDAP (AD prefered) for authentication.

3/30/2009 1:49:34 PM

Quote :

"MD5 is not encryption and is (IIRC) reversable. You want the crypt() function at a minimum"

Crypt uses MD5 or Blowfish on most systems. It can use DES or Triple DES which is reason enough to not use it at all.

Quote :

"i've never had cause to deal with encrypting passwords in a database before...what's best practice? is using just the md5() function good enough? i'm not dealing with anything sensitive, really, but i obviously don't want to store passwords in plain text"

Why have you ever had open passwords stored in a db? Bad bad quagmire. Yes MD5 + salt + client-side JS to do dictionary compares will be fine.

^LDAP is retarded for LAMP web applications.

3/30/2009 2:02:07 PM

its only retarded until you have to support it in the enterprise

3/30/2009 2:05:08 PM

That's not true at all. A well structured userDB has no problem with scaling or support. AD is a beast to support in all but large enterprises... which few websites ever need to worry about scaling to.

3/30/2009 2:08:05 PM

im not talking about scalability, im talking about end user experience and maintenance. Its so nice to be able to control access to all applications and all services through one directory. Its a huge pain in the ass to have to manage separate user accounts accross applications. For both users and support staff.

As for AD, it requires no brains to admin and is rock solid. You have to try really, really hard to fuck it up.

3/30/2009 2:14:18 PM

Quote :

"Why have you ever had open passwords stored in a db? Bad bad quagmire."

i have, quite literally, never done passwords in a db before...just never worked on a project where i had to work on an authentication system

Quote :

"Yes MD5 + salt + client-side JS to do dictionary compares will be fine."

that's what i was looking for...i didn't think about using a js dictionary comparison script

Quote :

"its only retarded until you have to support it in the enterprise"

i doubt i'll never need to manage more than 20-25 users, tops...it's just the nature of the system...so i figured this was as good a place as any to try it out

3/30/2009 2:26:54 PM

^^How does that have any effect on end user experience? We are talking about a WEB APPLICATION here. Not using AD does not mean you must have separate accounts per service or all, and USING AD does not mean you don't use separate accounts per service, because this is the damn interwebs, not a corporate intranet.

If you want to argue the "user experience", then we should all be using Live! logins or google identities for everything, and only using AD as a proxy for those services.

But that would be stupid, as is saying "use LDAP with AD for all authentication"

^There are some nice preboxed JS password validation scripts out there. Grab one, and plug in a password dictionary into it, it will increase the strength of your user's passwords ten fold.

[Edited on March 30, 2009 at 2:29 PM. Reason : .]

3/30/2009 2:27:52 PM

i generally use crypt and sha1, or zany combinations of both

3/30/2009 2:29:25 PM

most people don't actually store passwords in the database (encrypted or not)

they just store a crypt() hash in there and compare the two when a user authenticates, as you'll always get the same hash with the correct password.

3/30/2009 2:55:21 PM

Quote :

"Or be not gay and use LDAP (AD prefered) for authentication."

yeah, seriously, I don't think this guy needs any sort of LDAP or AD chicanery for what he's doing.


the hell are you thinking?

3/30/2009 3:04:18 PM

Quote :

"most people don't actually store passwords in the database (encrypted or not) they just store a crypt() hash in there and compare the two when a user authenticates, as you'll always get the same hash with the correct password."

yeah, i understood this...i wasn't very good about making that clear, though (i really didn't know of any other way to express what i was trying to do)...obviously, the password itself is never stored, just the hash

3/30/2009 3:09:32 PM

3/30/2009 5:45:26 PM

If its never going to be used in a corporate environment and you're never going to want to use the same authentication DB for another app, then db user auth is probably fine.

However even if you aren't, in the time it took you to read this thread you could have openldap installed and be using ldap for authentication already.

No where in the op is it stated that hes using it for a simple lamp app for shits and giggles.

Quote :

"How does that have any effect on end user experience? We are talking about a WEB APPLICATION here. Not using AD does not mean you must have separate accounts per service or all, and USING AD does not mean you don't use separate accounts per service, "

Not using LDAP almost always guarantees seperate user accounts for everything. If you create a custom UserDB for all your applications its simplified, but not optimal. The ammount of time you'll spend creating the DB + management tools is a waste of time when you can just grab any LDAP server and be done with it. You'd also have to be pretty dumb to use LDAP and create multiple accounts per service.

Quote :

"But that would be stupid, as is saying "use LDAP with AD for all authentication""

Doesn't need to be AD, AD is just my prefered LDAP server.


The bottom line is for minor, shits and giggles LAMP apps, ldap probably doesn't matter (wont hurt either). But if its something you're going to be putting into an existing corporate environment, use your existing LDAP server for auth.

3/30/2009 6:25:34 PM

MD5() is fine, unless your requirements say otherwise. If you're worried about collisions (where two passwords hash to the same value), which should be astronomically rare, use SHA1().

If you add salt that's unique to each user as well as salt that's unique to the deployment of the app, rainbow crack attempts will pretty much be totally curb stomped. For example, MediaWiki hashes your password as md5(userid||'-'||password)

3/30/2009 10:02:33 PM

i just figured i'd reuse one of my threads to ask a simple question...any reason in particular that doing something like this wouldn't yield any viable session variables?

index.php looks like this:

<?php
session_start();
ob_start();
include("connect.php");

if(isset($_GET['p'])) {
    $page = $_GET['p'];
}
else {
    $page = "logout";
}
if((!isset($_SESSION['id']) || (trim($_SESSION['id']) == '')) && ($page != "login")) {
    header("location:index.php?p=login");
    exit();
}
else {
    switch($page) {
        case "userarea": include("userarea.html"); break;
        case "invalidlogin": include("invalidlogin.html"); break;
        case "login": include("login.html"); break;
        case "logout": session_destroy(); header("location:index.php?p=login"); break;
        default: header("location:index.php?p=logout"); break;
    }
}

ob_end_flush();
?>

<form action="process.php" method="post" id="login">
    Username: <input type="text" name="user" maxlength="30" size="25" />
    Password: <input type="password" name="pswd" maxlength="30" size="25" />
    <input type="submit" class="button" name="login" value="Login" />
</form>

<?php
include("connect.php");
$user = $_POST['user'];
$pswd = $_POST['pswd'];
$query = "SELECT * FROM users WHERE USER='$user' AND PSWD='$pswd'";
$result = mysql_query($query);
if($result) {
    if(mysql_num_rows($result) == 1) {
        session_regenerate_id();
        $user = mysql_fetch_assoc($result);
        $_SESSION['id'] = $user['ID'];
        $_SESSION['name'] = $user['NAME'];
        session_write_close();
        header("location:index.php?p=userarea");
        exit();
    }
    else {
        header("location:index.php?p=invalidlogin");
    }
}
else {
    die("love is over");
}
?>

4/30/2009 12:17:25 PM

don't you need a session_start() in process.php?

4/30/2009 12:47:26 PM

^ yes, yes i do

this is why working alone sucks...there was a time when, after staring at the same code for 30 minutes, i'd just pass it along to a friend and have him point out the blatantly obvious solution

thxu

4/30/2009 2:01:42 PM

don't you love it when that happens?

4/30/2009 2:53:29 PM