[Top][All Lists]

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

Re: [OATH-toolkit-help] HOTP in HTTP Digest

From: Daniel Pocock
Subject: Re: [OATH-toolkit-help] HOTP in HTTP Digest
Date: Sun, 16 Jan 2011 13:17:28 +0100
User-agent: Mozilla-Thunderbird (X11/20100329)

Simon Josefsson wrote:
Daniel Pocock <address@hidden> writes:

What do you think if there were a hotp_validate_otp_callback() interface
that took a callback function to implement the 'strcmp' operation?  Then
you could call hotp_validate_otp_callback and provide a function pointer
to your function that generates a HTTP Digest response and comparing it
with what was received by the web server?
I actually had the same idea, although it made me start thinking about
an object-oriented rewrite.  However, a function pointer is probably
all that is needed.

Please test just released v1.4.0, I'm curious whether it solves your

My latest release (0.9.4) has a working OpenID solution based on HOTP - now that I've generalised that and made it work, I'm going to start looking at the issues of packaging and the relationship with the new OATH-toolkit solution.

One thing that already comes to mind is that I am using the gnulib MD5 for my HTTP digest code - so even if I take out hotp.c and link against liboath, we both have copies of gnulib in our projects (and in our binaries). Is that likely to cause issues? Or could you commit to providing the low-level stuff, like HOTP and MD5, to users of liboath?

I agree that HTTP Digest is not the most beautiful technology -
phpMyID actually creates a session cookie and then stops looking at
the digest headers.  In a real HTTP digest scenario, the user would be
prompted for their token code on every GET request (for every image on
the page, for example), so I'm in no hurry to make this into a full
Apache module.

TOTP may be slightly better here, as at least the same TOTP will be
valid for (typically) 30 seconds.  OTOH, you probably don't want to
enter a new TOTP every 30 seconds anyway...

However, an apache module should probably have a grace period where it
accepts an older OTP anyway, and the same could be implemented for HOTP

That's one of the benefits of building this framework - it will force people to start thinking about these practical use cases. The RFC may even need to be extended to endorse the use of grace periods and such things as required by protocols like HTTP.

reply via email to

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