[dev] Re: Password encryption (moved from IMP list)

[Eric Rostetter]

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

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

Okay.  But they somehow need to know to select it, that it would be more
secure in some way, and that it may break compatability with other things
outside of Horde if they use the same db for other authentication...

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

Basically it is easy to do as an optional module.

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

It won't be transparent, if we want to keep non-Horde db compatability
in check (which I'm not sure if we do or not).  But it can be easily done
as an option that the user can select, as long as any compatability problems
are documented.

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

Yes, agreed.

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

I agree.  I think such bad installs are few as a percentage of the
total installs, but that small percentage is probably still a fairly
large number.  And protecting people from their own mistakes or lack
of knowledge/skill is a good goal.

> > > 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 was also thinking:  If the network is sniffed and you use clear text
db replication, clear text network backups, the Horde web server and sql
are on different machines and talk in clear text over the network, etc.
So not just an https issue, but an issue of all types of direct and indirect
network traffic.  You can learn a lot by sniffing a network backup session ;)

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

It would be best to keep it.  You can't depend on the user setting up the
Horde/IMP realm settings correctly.

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

I didn't mean to suggest it was difficult.  I wanted to simply spawn a debate
over the implementation issues (complexity, compatability, difficulty in adding
initial user/password to db, etc) versus the possible results (including false
sense of security if we don't admit the flaws in it).

I also wanted to flesh out ideas of making this the default auth method
versus making it just another auth method, etc.

I think if you wrote this auth backend up, and documented it well, it would
be a good addition to Horde.  But I think the real success or failure will
be in how well it is documented, and of course if any one bothers to read
the docs ;)

> Kind regards,
>
> Scott

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

Why get even? Get odd!