Re: [OATH-Toolkit-help] OATH Toolkit 2.6.0

[Simon Josefsson]

David Woodhouse <address@hidden> writes:

> On Tue, 2015-05-19 at 13:58 +0200, Simon Josefsson wrote:
>> Long time, no release!  I'm kicking off working on oath-toolkit with
>> this release to fix some minor issues. 
>
> Welcome back :)

Yeah.  Sorry about the delays.  I really hoped to come back sooner.

>>  Now is a good time to ping me about anything I have neglected to do 
>> wrt oath-toolkit.
>
> How about making it easier to use for clients. I would love to have a
> function which I can simply pass the *filename* of a PSKC file, and
> have it just give me a token code. Updating the file as necessary, with
> some reasonable locking and power-fail-safety, if it's a HOTP token.
>
> As it is, there isn't even a simple way to use libpskc and liboath
> together, and even read the PSKC file and generate a token.

Right.  I recall your use-case for this now.  This was not the original
purpose for the PSKC code -- it was intended more as offline PSKC
manipulation tool to generate/parse data-in-transport rather than an
access format for working with data-at-rest -- so it is not surprising
that it doesn't handle this well.

I would be happy to support this use-case as well.  For TOTP it feels
quite nice -- you can have on-disk read-only storage in PSKC format and
use that behind a small-scale server.  For a large-scale server, you
probably would want a database for faster access, or some other format
that provides better on-disk confidentiality.

Thinking about how to implement this... libpskc doesn't know anything
about OATH OTP computation, so I'm thinking that this functionality is a
bit more high-level than what fits into either liboath or libpskc.

Would you be ok with doing this in a separate library, say, liboathpskc,
or something?  (Then I could move the liboath usersfile handling to that
library too, which is something I have been wanting to drop from
liboath.)

> Somewhat more out of scope, but it would also be *really* neat to be
> able to import tokens from other things, like the Java monstrosity that
> is McAfee Pledge :)

If the higher library was a bit more generic, that would be fine.  Right
now it would feel ugly to add that to libpskc.  It should probably not
be called liboathpskc then, but maybe something like libotp or lib2fa or
something.  I suspect there is some overlap with other existing projects
there though, but I'm happy to reinvent the wheel if there isn't a
suitable wheel around.

/Simon

signature.asc
Description: PGP signature