Re: lighttpd with empty password

This is a cryptographically signed message in MIME format.

--===============4677354183258722679==
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030402080601000204030601"

This is a cryptographically signed message in MIME format.

--------------ms030402080601000204030601
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi KP

Am 15.02.2018 um 15:20 schrieb KP Kirchdoerfer:
> On Mi, 2018-02-14 at 20:49 +0000, Erich Titl wrote:
>> Hi KP
>>
>=20
> 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.
>=20
> 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.
>=20
>>>
>>> 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.

This is not true as of 6.1.1.

You can access anything you want with a missing .htpasswd or a .htpasswd
without password.

Firefox will just display a message that it intercepted the redirectioon
and happily connect :-(

So this is just mocked up security.

>>> 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.
>=20
> True.
>=20
>>>
>>> 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.
>=20
>=20
>>>
>>> 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.
>=20
> 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).

Absolutely

>=20
>=20
>>>
>>> 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.=20
>>>
>>> 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?
>=20
>=20
> 1) Do not provide any .htpasswd with webconf, but take to save it, once=

> it is set (-> webconf buildtool.cfg needs to be changed)
>=20
> 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.
>=20
> 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.
>=20
> 4) the same counts for upgrades with upgrade tool, so I do not see a
> need for adding a script in post_upgrade

If we do not provide a .htpasswd in the package, then there is no way it
is saved in configdb.lrp as of the current buildtool environment. And I
have no clue what apkg -u will do.

>=20
> 5) 1 to 4 needs to tested.
>=20
>=20
>>>
>>> So the "problems" seen with the change to lighttpd are a benefit in
>>> hindsight.
>>
>> ??????
>=20
> I've never thouht a lot about webconf login cause I don't use it. The
> report on leaf-user changed that.
>=20
>>>
>>> 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.
>=20
>>> - 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.
>=20
> Here I've been unclear - let's not set the first password from port
> 80/8080 just from the console - and no default password.
>=20
> 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.
>=20
>> 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.
>=20
>=20
> All good advices - and some or all of them should be considered as
> improvements when installing the first time. But one step after
> another.=20
>=20
>> 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.
>=20
> 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.

I slightly disagree, security is not a feature it is a _must_.
I agree using an empty or predefined password is bad.
I disagree of omitting .htpasswd for the reason of not being able to
save it later.

>=20
>>>
>>>
>>> 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.
>=20
> Really?

Yes, as it allows encrypted communication, e.g. https

> I mean I haven't thought about it and need some further reading.
> If that is a good idea, why not?
> =20
> 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...?

I have not looked into the code at first installation as I disallow
password authentication on ssh anyway.

I _believe_ it is somewhere in .profile

#RPW=3D`grep root /etc/shadow | sed 's/root://' | sed 's/:.*//'`
#if test -z $RPW; then passwd; fi

and it is only true for root :-( , so no real security

You can see it is commented out in my case :-(

cheers

ET



--------------ms030402080601000204030601
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
A6wwggOoMIICkKADAgECAgEoMA0GCSqGSIb3DQEBBQUAMHUxCzAJBgNVBAYTAkNIMRIwEAYD
VQQHEwlTdGFsbGlrb24xDjAMBgNVBAoTBVRISU5LMRMwEQYDVQQLEwpDQSBTZWN0aW9uMREw
DwYDVQQDEwhUaGluayBDQTEaMBgGCSqGSIb3DQEJARYLY2FAdGhpbmsuY2gwHhcNMTQwMjI0
MDAwMDAwWhcNMTkwMjI0MjM1OTU5WjB/MQswCQYDVQQGEwJDSDESMBAGA1UEBxMJU3RhbGxp
a29uMQ4wDAYDVQQKEwVUSElOSzETMBEGA1UECxMKQ0EgU2VjdGlvbjETMBEGA1UEAxMKRXJp
Y2ggVGl0bDEiMCAGCSqGSIb3DQEJARYTZXJpY2gudGl0bEB0aGluay5jaDCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAMyJFgDhrDejCcqDw4qrn/PJrlyqJycEFBO8HH/Eme7Q
WShwskTLfs3b9vFyNy76H4Kd3q+uxb5UpibExFK9n/1l/YYobKXbL1SKAJGImOe5RyBigcMW
9qkbeb3tfdaj+JaNTCwpA2XiiMU2zSHHm8M7iu6rFNyx/mpbPyVZz1YmbO6ZN6Fzjj/LwAvb
VNKPrfFjjERDAENIZXj8c3OUVI67/lDbgRgLfea/7ovXPIby2hszTISjUEmqie9XjkeFK8Lf
iL2Fh6ui7d4qp7096DeZADqxWMwGj4lWvVcmIpMvLUJHga88j/ziJT0Fy1DDJX4ULX2ZyFgq
pY+PrMAc9VcCAwEAAaM5MDcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYI
KwYBBQUHAwMGCCsGAQUFBwMEMA0GCSqGSIb3DQEBBQUAA4IBAQC++xQWbBXJFP9tHl+Q+oTP
Tkkdp8xom3jdieVTHxKoqV7BD255GoyVu0nu4Y5ZgZxecMm9tuTx3yqJ56oKD2QCwSzewjee
SW27QKmku4+1NVTGCl9dljuKsOCVnw/3MrQDzii2BcpE23MJFOK/mthYP7wB0M0F5kQf/5mH
QukyNj1RFyuY2sFDMH9ZNkw7LluJcxL6iPhZp5yxHell9Qsd+uJwIgPfIKof79CqA0ZYhXum
GrVeS7RsyuRRev+eWwWvF2ntJjpI5O6SHZ8QBTg9AmM92Fev5OszY9v3xH582+Twl8Nl543U
kV9PDLtzCHueowguWdQB5n6LQqgADQBZMYIDmjCCA5YCAQEwejB1MQswCQYDVQQGEwJDSDES
MBAGA1UEBxMJU3RhbGxpa29uMQ4wDAYDVQQKEwVUSElOSzETMBEGA1UECxMKQ0EgU2VjdGlv
bjERMA8GA1UEAxMIVGhpbmsgQ0ExGjAYBgkqhkiG9w0BCQEWC2NhQHRoaW5rLmNoAgEoMA0G
CWCGSAFlAwQCAQUAoIIB8TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ
BTEPFw0xODAyMTgxODU0MjBaMC8GCSqGSIb3DQEJBDEiBCCY6774c0V08KkJWZ2mgUB1dQI3
o6PoBroRj8m7qfRy7jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQME
AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH
MA0GCCqGSIb3DQMCAgEoMIGJBgkrBgEEAYI3EAQxfDB6MHUxCzAJBgNVBAYTAkNIMRIwEAYD
VQQHEwlTdGFsbGlrb24xDjAMBgNVBAoTBVRISU5LMRMwEQYDVQQLEwpDQSBTZWN0aW9uMREw
DwYDVQQDEwhUaGluayBDQTEaMBgGCSqGSIb3DQEJARYLY2FAdGhpbmsuY2gCASgwgYsGCyqG
SIb3DQEJEAILMXygejB1MQswCQYDVQQGEwJDSDESMBAGA1UEBxMJU3RhbGxpa29uMQ4wDAYD
VQQKEwVUSElOSzETMBEGA1UECxMKQ0EgU2VjdGlvbjERMA8GA1UEAxMIVGhpbmsgQ0ExGjAY
BgkqhkiG9w0BCQEWC2NhQHRoaW5rLmNoAgEoMA0GCSqGSIb3DQEBAQUABIIBAFa9fskQTlVj
f8tejWwgNj5CW03x6CYSnVfqxIaV9fCBaso8abpIDhXTYhueaMJv1owfpwFOfF01kRLahfdV
kPELmL1dThardwotQ8ZGsewILKMzRy5MbkOCgPijuyGuKFRayTZhKlHL/iYXwW62HQD/QmO/
RRnKmfCWROaZKXMtH3rZv3UQjD3QHpYQ2v3DvE9SoL/wnnDCJnrFMIOQQbcalPAq3kFiiwnD
Z2PxgGnZUVTrZHzHbeKvX7iRd17ADWKHI/RfxKxodwAtqpPuiTFCpNDh97YU+rNTI3STbtZS
nJNS5gE54UF1Oc4FVOZJ1KF9Yoq61UIsa7mZKQRTv/oAAAAAAAA=
--------------ms030402080601000204030601--


--===============4677354183258722679==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
--===============4677354183258722679==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


_______________________________________________
leaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

--===============4677354183258722679==--