Re: lighttpd with empty password

KP Kirchdoerfer via leaf-devel <[email protected]> Sat, 17 Feb 2018 00:40:47 +0100
Newsgroups gmane.linux.leaf.devel
Message-ID <[email protected]>
(resent, first try ended in SF outage)

Hi Erich;

On Di, 2018-02-13 at 19:14 +0000, Erich Titl wrote:
> Hi KP
> 
> Am 13.02.2018 um 18:10 schrieb KP Kirchdoerfer via leaf-devel:
> > Hi Erich;
> > On Di, 2018-02-13 at 13:31 +0000, Erich Titl wrote:
> > > Hi
> > > 
> > > Here a possible solution for the distribution of webconf with an
> > > empty
> > > passsword.
> > > 
> > > leaftester# more .htpasswd
> > > admin:2Dp46HA3ULDxA
> > > 
> > > This password has been created using
> > > 
> > > pwcrypt ""
> > > 
> > 
> > Been there done that, it doesn't work.
> 
> It does work, please state your observation.

Technically it works, but one don't even has to change the password to
get full access, so it's worse than before where we have had an
insecure web access, but at least the user was forced to change the
default (empty) password to continue.

> > 
> > The previous behaviour with mini_httpd was with an empty password
> > it
> > does not show anything unless you add a password after login as
> > admin -
> > it always pointed to passwd.cgi regradless what link you wanted to
> > open
> > in webconf.
> > Though everyone able to connect was able to login and change the
> > password and get acccess to the router.
> > 
> > This is in reality an illusion of security.
> 
> This is not an illusion of security, this is no security, but
> this is the way you can login with lighttpd and admin without knowing
> a
> password, as this is just the empty password.
> 
> - You _cannot_ login using lighttpd _and_ a missing .htpasswd right
> now.
> - You _cannot_ login using lighttpd _and_ an empty password field in
> .htpasswd right now.
> 
> So user access is broken, this method gives you a chance to login and
> _change_ the password to your own discretion. You will not be able to
> do
> that with the current empty password field.

True.

> > 
> > With lighttpd a really empty password in .htpasswd does not allow
> > any
> > login.
> 
> Yes it does not, but with a encrypted empty password it does.


> > 
> > The approach above allows to login with an empty password, but as
> > you
> > have a password, even an empty one, you have full access. Worse
> > than
> > before - and no better than having an open router without any
> > protection.
> 
> I don't get your idea. This enables the user to do _something_ just
> like
> before. With the current setttings the user is left alone.

We've learned (at least I have learned the last days) either way
(previous and with your patch) is without any real security as long as
you install webconf (esp if opened to WAN e.g. by accident).


> > 
> > Commercial routers often uses a default password, like "1234" for a
> > device I've installed recently in modem-mode before the LEAF router
> > and
> > you shall change it, but it works also without any changes. 
> > 
> > I think we can do better.
> 
> Commercial routers do exactly that and I agree it is bad. Now with
> lighttpd being a bit more restrictive than mhttpd(s) when it comes to
> .htpasswd we are in a small impasse.
> 
> > 
> > We should get rid of any mimic to allow access from anywhere
> > without a
> > proper password choosen by the user.
> 
> Do it with a script when starting a newly installed LEAF, that is
> fine.
> Do it with a post_install script in upgrade.
> 
> But what about users choosing to manually upgrade like Timothy?


1) Do not provide any .htpasswd with webconf, but take to save it, once
it is set (-> webconf buildtool.cfg needs to be changed)

2) try to add a script for first install if webconf but no .htpassswd
create one during installation like root password - if the user chooses
an empty one here so be it.

3) Users with a .htpasswd, hopefully changed password in the past, and
it won't be acffected when upgrading, because there is no default
.httpasswd any longer.

4) the same counts for upgrades with upgrade tool, so I do not see a
need for adding a script in post_upgrade

5) 1 to 4 needs to tested.


> > 
> > So the "problems" seen with the change to lighttpd are a benefit in
> > hindsight.
> 
> ??????

I've never thouht a lot about webconf login cause I don't use it. The
report on leaf-user changed that.

> > 
> > I tend to go the way:
> > 
> > - no access to webconf without a real password as default
> 
> Choose one, then publish it like the commercial vendors :-) Nothing
> really new and not secure at all.

> > - it should be possible to change the web login password from the
> > webpage
> 
> This is a hen-egg problem with lighttpd. If you find another solution
> which is _secure_, welcome to the club.

Here I've been unclear - let's not set the first password from port
80/8080 just from the console - and no default password.

There will be no access to the webinterface unless a password has been
set from console.
But we should allow to add users/passwords later from webconf.

> Here is my idea of securing the system
> 
> - If someone gets near the console the system is compromised anyway.
> No
> security.
> - I do not allow ssh with passwords, only ssh keys.
> - I only allow https access and that typically only from the local
> zone,
> maybe even restrict it to single ip addresses.
> - I _never_ allow web access without a password.


All good advices - and some or all of them should be considered as
improvements when installing the first time. But one step after
another. 

> The problem with the current lighttpd config stems from the
> observation
> that the current method does not work, neither an empty password
> field
> nor a missing .htpasswd. So the router cannot be reached using the
> web
> interface with the current settings. The proposed change allows
> access
> with no security, just like your suggested interface would.

Yes but this has to be changed.
Security is a feature not a bug. And while we are trying hard to make
upgrades as seamless as possible, IMHO there are times when improving
security is more important than user experience.
I guess we both agree here in general, question is, if this is one
these times - I'd say yes.

> > 
> > 
> > In step 2 we should force to use https instead of http to access
> > the
> > router.
> 
> This is easy but requires a certificate. Do you want to provide one?
> Any
> certificate is better than none.

Really? 
I mean I haven't thought about it and need some further reading.
If that is a good idea, why not?
 
But if we agree to set the password during installation and get that
done, creating certificate shouldn't be hard as well. Maybe a more
comprehensive solution...?

regards kp



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot