Is there any plan for http digest access authentication

[hjfbswb]

I'm using V3.1.0 to build a web server on an embedded device that supports both HTTP and websocket protocols, and It seems that libwebsockets does not support http digest authentication(rfc2617, rfc7235).

HTTP protocol needs to support digest authentication mechanism. Is there any plan to support digest authentication mechanism at present?

Thanks you.

[lws-team]

Right, it supports Basic only atm. Basic is pretty cruddy, but if used with properly verified tls, it's not as insecure as it looks.

If you want to do it without tls, Basic is completely insecure.

I don't have a plan to implement it in the very near future. If you want to add it, a patch is very welcome... Basic is already there

https://libwebsockets.org/git/libwebsockets/tree/lib/roles/http/server/server.c#n969

and the sequencing is the same; there are no new states just needs to look for "digest" auth type as well, parse the additional tokens... look at lws_tokenize

https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-tokenize.h
https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/api-tests/api-test-lws_tokenize/main.c

... the default md5 is not useful any more but the server can define the algorithm, look at lws_genhash...

https://libwebsockets.org/git/libwebsockets/tree/include/libwebsockets/lws-genhash.h
https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/api-tests/api-test-jose/jws.c#n655-667

... genhash is the same api independent of the tls backend being openssl or mbedtls.

[hjfbswb]

Thanks for your replay.

In our system, user names and passwords are dynamic, and administrators can create and delete users, as well as modify a user's password, and they are stored in a database.

Therefore, it is difficult to use a file to specify the user name and password.

Can I implement digest authentication using a callback?

For example, LWS provides a callback that allows users to authenticate HTTP requests, and the user can then verify HTTP digest authentication using LWS provided utility functions in the callback.The utility functions include an interface to parse the Authorization header field and a method to calculate the response field using user-supplied username and password.

I saw the callback reason LWS_CALLBACK_CHECK_ACCESS_RIGHTS, but it seems not suitable to do this.

[lws-team]

Despite what I said before, I started working on a patch for it.

But I discovered when I start to test it against a browser, neither Chrome nor Firefox support RFC7616 which formalizes how to use better hash algorithms than MD5. Current Chrome and Firefox only support MD5.

See this mozilla bug still open from 11 years ago (!)

https://bugzilla.mozilla.org/show_bug.cgi?id=472823

The callback is a good idea but does this MD5 reality cause you to doubt the usefulness?

[hjfbswb]

Thanks for your work ^_^.

I considered using callback not for this MD5 reality, but for the following two reasons:

First, it is not safe to keep both the username and password in clear text in a file.

Second, in our system, it would be difficult to get a file containing all the user names and passwords. Even if I generate a file that contains all the user names and passwords, since the user names and passwords may be changed at any time, that means I may need to modify this file at any time, which is likely to conflict with the LWS, which will need read this file at any time.

[lws-team]

Adding the callback is fine, it's relatively simple on top of basic auth or compared to digest... nobody's arguing against it.

However only md5 is supported and no browser has implemented anything stronger for 11 years... it really means this whole method is effectively dead doesn't it?

[hjfbswb]

I am building web services defined by ONVIF protocol using LWS, and digest is still the primary authentication method in the latest document of ONVIF protocol (see attachment).In the ONVIF protocol, the device as a server communicates not with the browser, but with the ONVIF client, so the md5 reality of the browser has no impact on me. And In reality, most of the time, onvif clients still use digest authentication.

[lws-team]

I got most of it done but I don't have time to finish it.

Please fetch current master and then pick this patch from branch digest-auth.

cf36cba

It has the cmake and parser digest pieces in nicely using the tokenizer. But it doesn't perform the RFC7616 auth steps... it has the code in to show how to cleanly do the string composing and then the hashing of it. I think you'll find adding the auth pieces is significantly easier than starting from scratch.

Because unlike Basic auth, digest specifies a hash, the server can store pre-hashed A1 (see p10 of RFC7616) MD5 hashes instead of the password directly. It's better than plain but it has to be MD5, so it's not a great deal better in reality.

If you want to send a patch-on-top after finishing it off (it might make sense for digest to only offer the hash compare callback rather than bothering with a file) it'd be great.

[hjfbswb]

Thanks, I will try to finish it within 2 weeks.

[biterrorr]

I would love to have an authentication callback so I could verify the user/passwd from an sqlite database instead of having a passwd file on disk. Basic auth is ok with me, I just need the callback.

Any hope of getting one soon? :-) Thanks!

[lws-team]

I think that's part of what hjfbswb has in mind.

Of course, if you have an sqlite database on disk with passwords in it, you pretty much have the same thing as a passwd file on disk security-wise. It's not really avoidable since Basic auth doesn't include any hashing, the credentials are passed on the connection unencrypted.

RFC7616 does hash them but only md5.

[biterrorr]

Yes, security-wise it's the same, but this is an embedded-like box which has all changing information in the database, so I would like to skip maintaining an external password file and regenerating it every so often. I need to do the same thing for other things like dhcp as well..

[lws-team]

Understood... the callback is a good idea anyway.

[biterrorr]

Has the basic auth callback been implemented? I could put it into use now :-) Thanks!

[lws-team]

Patch is welcome (from anyone)...

[lws-team]

Good job I did not hold my breath...

[ilsme]

What about digest auth support for http client?

[lws-team]

Sure, send patches.

[ginolaku]

I would like to see digest auth support for http client with the v4.2-stable (from yocto receipt) as
previous patch from branch "digest-auth" is for v3.x

[lws-team]

If it had been completed it would be in later versions already. The patch there is just a partial solution waiting for someone to finish it off. Sometimes it feels maintaining this is more like being an assassin or an exorcist, since when I ask for help and contribution, "people disappear".

No new features will get added to v4.2 since it's a stable release. The path would be someone cooperates to get it working in main, make a new release and then update the yocto recipe to point to the new release.