[dev] Password encryption (moved from IMP list)

[Scott Courtney]

On Tuesday 17 June 2003 11:32, Eric Rostetter wrote:
>
> 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.

What I was proposing was to implement a new authentication module, parallel
to the existing choices. The novice would only have to select the new module
in the config file, just as they now select 'imap' or 'ldap' or whatever
scheme is desired.

>
> > 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.

I feel the same...I haven't analyzed the existing Horde authentication code
closely. So I don't know yet if my idea can be implemented cleanly and with
no increase in configuration difficulty. I'll take a more detailed look in
the authentication code to see whether it's feasible or not.

>
> 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.

I actually agree with you. If what I propose can't be implemented in a way
that's transparent to the normal Horde installer/user, then it's probably
not worth doing.

>
> > 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.

"Protects" is a relative term here. It doesn't "fully" protect you, but it
does make their job more difficult. See below for further comment. 

> 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.

Yes, it only protects against pre-encrypted brute force attacks against the
DB directly. My point is, isn't that better than nothing? Security is an
iterative process, not a final destination.

I've seen places where MySQL was accidentally configured to allow
SELECT access to anonymous users from any host on all databases and tables.
The notion that the DB is secured from access is not universally true.

> 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.

Properly configured LDAP should be encrypting passwords as well. I don't know
the details of whether LDAP uses any kind of variability or just encrypts the
password alone. A properly-configured LDAP directory allows only "authenticate"
access to the userPassword attribute, rather than world read access.

>
> > 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...

If the network is sniffed, and you're not using HTTPS protocol, then all bets
are off. Agreed.

I'm still thinking that perhaps this can be implemented in a way that is not
harder for the novice, though. If I can't find a way to do that, then I agree
with you that the game is not worth the candle.

>
> > 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).

Yes, that's true. I should have mentioned that in my case I had several
independent authentication databases (for different web sites) on a single
physical server, and I was concerned that someone might have the same user
name and password in two different sites on my server. Perhaps for Horde this
is a non-issue. I could see dropping the numeric value from the hash string.

>
> > 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.

Emphasis intended on the word *single*. The attacker would have to try
the dictionary attack against each user for each dictionary word, not
just once for each dictionary word. I view that as multiple attacks rather
than a single attack. It goes from O(1) complexity to O(N). Not a huge
improvement, but something.

>
> > 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.

Again, I don't disagree with you at all. If this can't be implemented easily
and cleanly, then it's not worth doing. I think it might not be as bad as
you suggest, though. If I'm wrong, then I'll happily drop the suggestion.

Kind regards,

Scott

-- 
-----------------------+------------------------------------------------------
Scott Courtney         | "I don't mind Microsoft making money. I mind them
courtney at 4th.com       | having a bad operating system."    -- Linus Torvalds
http://4th.com/        | ("The Rebel Code," NY Times, 21 February 1999)
                       | PGP Public Key at http://4th.com/keys/courtney.pubkey