libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Some questions about the example "digest_auth_exampl


From: silvioprog
Subject: Re: [libmicrohttpd] Some questions about the example "digest_auth_example.c"
Date: Thu, 3 Mar 2016 20:24:03 -0300

After this new explanation finally I fully understood. Thanks a lot Christian! :-)

On Thu, Mar 3, 2016 at 11:33 AM, Christian Grothoff <address@hidden> wrote:
On 03/03/2016 02:00 PM, silvioprog wrote:
> Very good explanations. I'll comment some of them and make a new
> question at the bottom.
>
> On Thu, Mar 3, 2016 at 5:06 AM, Christian Grothoff <address@hidden
> <mailto:address@hidden>> wrote:
>
>     No, see:
>
>     http://security.stackexchange.com/questions/24425/what-is-the-opaque-field-in-http-digest-access-authentication-used-for
>
>
> If I understood, I just need to do something like "opaqueStr =
> generate_md5(generate_uuid())" generating a unique opaque for each
> request and use it instead of the static MY_OPAQUE_STR.

No, that's not exactly the idea, and I stuff should break if you create
a new opaque per request.  But it should be safe to create a new value
for each process you start.  Still, generally unless you have a
complicated multi-site setup, there is no reason to mess with opaque.

>     MHD_OPTION_NONCE_NC_SIZE is optional, the value will default to 4 if you
>     specify none. Note that 4 may be a bit small for real uses.
>
>     You can technically also leave out MHD_OPTION_DIGEST_AUTH_RANDOM, but
>     then you're reducing the security of your authentication as you are no
>     longer using salted hashes.
>
>
> I'll use that. If I understood, I can use these two flags in Digest and
> X.509 auths. Does the timeout passed to MHD_digest_auth_check() need to
> be the same passed in the MHD_OPTION_NONCE_NC_SIZE?

MHD_OPTION_NONCE_NC_SIZE is an array length,
while timeout is a time value in seconds.
They are unrelated and don't have to be the same numeric value.

>     Provide a cryptographic salt, and the size of a buffer to manage
>     nonces.
>
>
> The size of "rnd" on memory or the length of characteres in the "rnd"?

The size is the size of the binary buffer in bytes.  I usually manage to
stick to using "size" for bytes-of-memory and "length" for the number of
entries in an array or the length of a string.

>     > The example uses the "/dev/urandom" feature, but I need to make a
>     > cross-platform solution, so can I use a hash like a UUID (I can generate
>     > it using a own function) instead of using urandom?
>
>     For the opaque, sure.  For the salt, you may want to make it vary each
>     time the program runs.
>
>
> Just to check if I understood:
>
> - instead of using the static MY_OPAQUE_STR, I need to generate a hash
> for each request, something like a md5 from a UUID;

Nope, you usually simply don't need to change it, but you can change it
if you feel a constant is bad; however, you do need to generate a
consistent value for the same authentication domain.

> - the timeout of the MY_OPAQUE_STR need be same of the
> MHD_OPTION_NONCE_NC_SIZE;

Nope. Those are independent.

> - MHD_OPTION_DIGEST_AUTH_RANDOM needs a hash for each server startup,
> something like a md5 of the server startup time;

Well, that might do, but both md5 and server startup time are not
particularly great sources of entropy.  This may give you maybe 20-24
bits of entropy, while you want ~128.  Again, YMMV depending on your
security requirements.

> - MHD_OPTION_NONCE_NC_SIZE specify the timeout for the nonce (salt)
> specified in the MHD_OPTION_DIGEST_AUTH_RANDOM;

Nope, it specifies the length of the array in which we track nonce
counters to prevent replay attacks.

>
> And now the new question: is this example validating the user name? I
> just put any username and it allows the login, checking only the password.

The example allows any username with password 'testpass'. You'd have to
check some "if (0 == strcmp (username, "testuser"))" to restrict the
username, or user the username to lookup the password to validate the
user name.

--
Silvio Clécio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]