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

[Daniel Pocock]

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
> issue.
>   

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
> too.
>
>   
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.