[imp] Newbie question - got it installed. now what ?

[Eric Rostetter]

Quoting Scott Courtney <courtney at 4th.com>:

> On Monday 16 June 2003 23:21, Eric Rostetter wrote:
> > > insert into horde_users values ('test', PASSWORD('test'));
> >
> > You need to use md5() instead of password().
>
> Okay, someone said suggestions were okay on the list, so here's mine for
> today:

Suggestions always welcome.  And it is interesting, and I'd love to here
why my comments below are wrong.  Maybe this should move to another list
though like the Horde or dev mailing lists....

> Having a password column that contains only the crypted password (md5 or
> whatever) is not as good a security practice as having a more variable
> password.

Sure.  But as you state below, if you need or desire to be compatible with
other systems, you can't create new schemes.  Also, the more complex the
scheme, the harder it is for people to implement.  Many Horde implementors
don't have the skill level to understand anything more complex than using
a builtin function as-is.

> I've written a PHP-based content management framework for a news portal
> site that I run. Here's what I do for password storage:

Sounds great, though I've not analyzed the code.  But the added complexity
of setting up the passwords, and lack of possible compatability (however
small the current amount of compatability is) between Horde's passwords
and other system's passwords, would worry me slightly.

As such, I could see implementing something like this as an additional,
alternative scheme in addition to the others, and putting something in
SECURITY about it.  But I'd be worried about making this the default or
normal sql scheme, as it would raise the bar too high for some new
implementors.

> To check the password, take the credentials presented by the user, read
> the pseudo-random value from the database, and use that value to crypt
> the credentials using the same algorithm. If they match, good login.

This in no way protects you from anyone who has the password strings (has
compromised your db), since the random numbers are clear text in the database.
It also doesn't protect you against brute-force attacks against
the application, since the application takes care of encrypting them
with the random number.  So it only protects against pre-encrypted brute
force attacks against the db directly. Hopefully you've secured the db
from access anyway, so this wouldn't be much of an issue in most cases.

As such, I see this as only useful in some small number of cases (public
database).  In fact, I'd say the most common place for this kind of scheme
might actually be in ldap rather than sql, no?  Ldap runs off passwords,
and is more often a public facing db than sql would be.  Or maybe that just
reflects my ignorance of how people really implement ldap vs sql.

> This approach won't work for using MySQL's own direct authentication, but
> if your code does its own authentication check in PHP, this is more
> secure than just hashing the password itself.

Yes.  But harder for the novice to setup and use, and less compatible with
other systems.  And not much protection if the db is compromised, or the
network is sniffed, etc.  Unless I'm missing something...

> With this approach, the password column in the database is not the same
> for two users who happen to choose the same password.

Just hashing the username+password would accomplish this also (unless you
somehow have duplicate usernames).

> The idea is that
> the values of the password column in the database aren't directly
> attackable by a single dictionary attack.

Sure they are.  It just takes longer ;)  And if you attack them via the
application then there is no difference.  Only protects against direct
db attacks, not application attacks.

> You have to dictionary attack
> on each pseudo-random value that appears, and for each different username,
> not just once for each resulting md5() hash.

Correct.

> If you're interested in seeing my code, I'll be glad to send a snippet off-
> list. I've released my stuff GPL, so you're free to use it if you find it
> helpful in any way.

I'll leave that up to others to decide.

> This certainly isn't rock-solid, but it's an improvement in security and
> it comes at minimal cost in terms of code complexity.

But what is the cost in setup complexity vs the actual security benefit.
Doesn't look sufficient to me, but I'm interested to hear others explain
why I'm wrong.

> Scott

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!