If I had a choice... but I don't. IE it is. And no SSL - it's not required in this case.

I hear you - but it's an internal network that anyone on that network would have access to the carddav anyway. I'm hard coding the log in page as it is. I supposed some mythical day someone could set up a carddav share that actually required authorization... On 2016-04-01 5:14 PM, Ján Máté wrote:

With basic auth and simple http (without SSL/TLS) the username and password is sent over network in plain text form.

So technically it will work without https, but using http + basic auth is a security NIGHTMARE.

JM

...

On 01 Apr 2016, at 11:57 PM, Admin - Muskoka Auto Parts Limited <admin@muskokaauto.com> wrote:

If I had a choice... but I don't. IE it is. And no SSL - it's not required in this case.

Hi,

On 04 Apr 2016, at 10:05, Tobias Mueller <muelli@cryptobitch.de> wrote:

Hi.

On Fri, Apr 01, 2016 at 11:41:39PM +0300, Ján Máté wrote:

...

whenever it's possible avoid digest Can you elaborate on that?

It should be obvious that the security properties of digest auth are much better than those of basic auth. So I'm left wondering why you give that recommendation.

if you compare Basic vs Digest then yes, digest is better (even if it is vulnerable to a man-in-the-middle attack, your server cannot use strong password hash, ...). If you read the documentation, there is a mention about incorrect implementation of Digest auth in lot of browsers (especially if used from JavaScript in combination with preflight requests, etc.). So really don't use digest, use basic auth in combination WITH SSL/HTTPS. Cheers, JM

My preference would be SRP, but that's not widely supported :-/

Cheers, Tobi

If I might interject, digest is widely accepted as laughably weak and thus a generally unnecessary layer when the entire session (including the authentication process) is already secured via SSL or TLS. "If we can encrypt it once, why not encrypt it twice?!" - The crazy sys admin I would compare Digest Authentication to requiring a second password for login, but that password can be no longer than 3 characters and is brute-forced independently; you're much better off to increase the length of the original password (key length for our purposes) or explore other avenues of security that don't unnecessarily increase complexity/server load (one-time passwords maybe? The world is your oyster). If you're genuinely interested in the topic, I'd be happy to elaborate on anything unclear. --- Colin Purcell | IT Administrator On 2016-04-04 5:39 am, Tobias Mueller wrote:

Hi.

On Mo, 2016-04-04 at 11:21 +0300, Ján Máté wrote:

...

If you read the documentation, there is a mention about incorrect implementation of Digest auth in lot of browsers (especially if used from JavaScript in combination with preflight requests, etc.). hm. that's odd. The only thing I could find is https://github.com/equaeghe/infcloud/blob/master/readme.txt#L72 which currently reads:

4.) Digest authentication problems and how to solve them (if your server uses digest auth)     - Why digest authentication is problematic?       Lot of browsers have wrong or buggy digest auth support (especially if used from JavaScript).     - What to do to solve this problem?       a.) Disable the digest authentication and enable the basic authentication in your server config (NOTE: ALWAYS use SSL /https/ for basic authentication!)       b.) Alternatively (if it is not possible to switch to basic auth) you can try to enable the globalUseJqueryAuth option in config.js (NOTE: there is no guarantee that it will work in your browser)       NOTE: if you want to use the auth module /see 6.) c.) below/ you MUST use basic auth (there is no digest auth support in this module)!

Unfortunately, it doesn't point to any actually identified problem. So for now, the claims are not substantiated and it looks as if theterrible security advice is given without reason.

...

So really don't use digest, use basic auth in combination WITH SSL/HTTPS.

Sure. But that's two separate issues, as TLS is not used for (client) authentication. You probably want both, a reasonably secure encryption as well as a reasonably secure authentication.  Recommending to use the less secure authentication without (very) good cause seems ill-advised to me.

Cheers,   Tobi