[dev] Re: [cvs] commit: passwd/config .cvsignore backends.php.dist conf.xml passwd/lib Driver.php Passwd.php base.php passwd/lib/Driver ldap.php sql.php passwd/templates/main main.inc passwd main.php

[Eric Rostetter]

Quoting Mike Cochrane <mike@graftonhall.co.nz>:

> > And, as a side effect, a module much easier to exploit by hackers to hack
> > passwords...
> 
> I'm not sure what you mean by this one... You still need to know the current
> password so this is the same as any other login.

Purely hypothetical discussion...

In CVS HEAD, guest services are advertised off a link on the login page.
This means many search robots will include these pages.  This gives the
hackers a instant list of people using the module with guest access for
them to try to attack... (Via google, yahoo, etc)

Now, I have a web server with Horde/Passwd on it.  You can't login (no
telnet, ssh, etc) so there is no way to brute force this from the network
other than the Horde login screen.  It is running poppassd for password 
changes, but that is bound to loopback so it can't be hit from the network.
Only way to hack is via the Horde login page...  Okay, that's a big hole,
but it is at least a single hole...

So I'm feeling fairly safe.  Only one possible way to exploit brute force
attacks (well, excluding all the others like social engineering, bugs in
the web server, etc).

Until you set passwd to guest.  Now they can find it via google (since I
didn't exclude it in my robots.txt file, etc).  Thay can access directly 
this page and start guessing username/password combinations.  Since most
poppassd servers don't treat security as seriously as normal login
proccesses, they probably have a much better chance of getting in via poppassd
than they would via telnet/ssh/etc.  In fact, they probably have a better 
chance this way than via the Horde login page.  (Since the poppassd server
probably isn't pam aware, doesn't care about how many times you try, etc).
Plus you've bypassed things like tcp_wrappers, firewalls, etc. that might
normally be in place to help with telnet/ssh/poppassd/etc.

Well, I could go on with a bunch more hypothetical stuff.  There are different
cases for every type of auth (sql, ldap, smb, poppassd, etc).  It isn't worth
it to go on...  The point is, you don't know what the security setup is of
the end-user.  So don't make a default any action which could lessen that 
security in any non-required way.  Making passwd a guest service IMHO does
this -- add's additional security risk as the default value.

> - Mike :-)
> 
> --
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe@lists.horde.org


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

Why get even? Get odd!