Re: [Otpasswd-talk] Changes in code and documentation. ;-)

[Hannes Beinert]

On Sun, Jan 3, 2010 at 16:38, Tomasz bla Fortuna <address@hidden> wrote:
> Dnia Sun, 3 Jan 2010 16:05:30 -0600 Hannes Beinert <address@hidden> 
> napisał(a):
>
>> I do have a bunch of questions/comments that have come up in the
>> course of my messing around with the documentation.  And I realize
>> that anything I write is out of date the moment I write it!  :-)
>
> Nah, there wasn't THAT much changes. ;-) However it's true I've
> concentrated on things which further changes might lost users or change
> state (that's why I did alphabet change and key removal). I hope I
> already fixed most of docs.

No worries -- I was expecting that things would change.  I think there
are two primary issues with writing documentation -- first, to just
get something (anything) down on paper, and second, to keep it up to
date.  Hopefully with the two of us, we'll meet both goals.

I hope you don't mind if I come in behind you and tweak some of the
updates you made (not the content, just the format, or perhaps a
little of the language).  Your English is really superb, but one can
almost always tell a native Slavic speaker from a native speaker of
romance languages.  It's always the articles and the smaller cardinal
numbers.  There's so much information packed into the declensions of
Polish words that an English-speaker just doesn't expect.  I'm sure
that the opposite is true when an English-speaker speaks/writes in
Polish, too.  Sadly, that's a perspective I don't have.  :-(

>> With respect to your specific question...  I'll have to think about it
>> a bit.  However, I do think it might be nice to have a date along with
>> the recent failure count, perhaps, so that one could get an idea of
>> the rate of failures.  I'm not sure.
>
> I thought of resetting recent_failures after warning is printed to user
> (so he sees how many failed tries happened since he last logged in
> correctly) and failures - hm - no idea currently. Admin might have
> ability to clear them or no ability at all. Like distance in cars.

Yeah, that makes sense.  Mostly I'm just interested that some
information exists to detect break-in attempts and/or compromised
keys, or whatever.  If the user actually marks off the used passcodes
on his passcards, that would already be a huge step.

>> Also, I think that it might be useful to have either a more
>> complicated "contact" field with subfields, or multiple contact
>> fields.  Personally, I might want multiple channels -- any combination
>> of email, SMS, IM, or things I can't think of at the moment.
>
> Currently it can be done a bit. One user can have phone number, second
> an email and OOB script can handle all situations. If we decide that we
> want one user to have few channels possible then it also requires some
> changes in PAM interface. It's not enought to define that OOB is
> supposed to be used all the time, or after '.' command. but one must
> also define channel somehow. It's not trivial.
>
> We can do something like 'GECOS' field in /etc/passwd. Keep this state
> location untouched but allow multiple entries delimited with, say,
> '%' (it's kind of shell safe and not allowed currently). It's length
> would have to be enlarged... but we don't have field limit then and
> script can be somehow informed about which field to use. Hm.

Yes, I was actually thinking of the gecos field, too.  That might be
the best way to do it, since I suspect that any attempt to reserve
specific fields for specific functionality will become obsolete before
one finishes writing it.  A single field of sufficient length, and
which can be parsed, is probably the most flexible.

>> I see that you're including just the checksum of the static password.
>> If one were to want to create a OTPW-like password entry where the
>> user would enter a concatenation of the static password and the OTP,
>> would there be enough information present in the state information to
>> parse that?  Or do you have some other method in mind?  I'm just
>> thinking aloud here, as it were.  :-)
>
> Yes, it's enough if we know code length (and we know it), I'm going to
> split input in the first place to
> xxxxxyyyyy
> where number of y is exact codelength and then calculate sum out of
> xxxx.
>
> But I was going to ask similar question too. ;) Is it ok to prepend it
> with static password or just do two prompts?
> Static password: <...>
> Passcode  1B [8]: <...>

Personally, I think it would be nice to have this be configurable, as
well as having a configurable static password prompt...  however,
generally speaking, my feeling is that the less information one can
give an attacker, the better.

In other words, if the prompt is just "password:", then the attacker
wouldn't know where it comes from -- OTPasswd or getty.  And, I'm sure
there are people who would object to multiple prompts (just as I'm
sure that there are also people who would object to a single prompt).

> Combining both makes it more difficult for attacker to determine if
> static password was correct? I guess no, if attacker knows
> codelength... So well. I guess it's just aesthetic question.

I suppose there is a chance that an attacker could stumble upon the
static password during a brute force attack, somehow.  However, that
would increase the key-space he would have to try, making it a
nightmare for him.  And, because the static/OTP lengths are an issue,
he would either be trying the OTP keyspace, or the OTP+static
keyspace, but couldn't be trying both simultaneously.  So, yeah, I'm
thinking it's mostly aesthetic.

> Static password: <...>
> Passcode  1B [8]: <...>

This actually raises a question on my list.  In most of the
discussions and software examples I've seen regarding PPPv3, a
"passcode address" (or the passcode prompt) was always RRC[card].  In
the otpasswd utility, however, you are requiring CRR[card].  This
raises a bit of a consistency issue, I think.  One of the things I
actually rather like about RRC[card] is that since "C" is a letter,
the string doesn't need the brackets to be parsed (although that might
inject other syntax ambiguities or more difficult code).

Another issue that I noticed in reading some of the updates you made
to the otpasswd(1) man page was that you wrote that the codelength
could be changed at any time.  Is this not problematic?  Given that
the passcard has some general formatting specifications (size,
mostly), and that each passcode can be addressed by its position on a
passcard, this can lead to some difficulties, I think.  For example,
if I generate my key with a 4-char codelength, then the passcode
addresses will be computed based on passcodes of, say, 10 rows and 8
columns (80 passcodes per card).  The reason for this choice is that
the passcard is about credit-card size.  Now, if the codelength is
doubled to 8-chars, to maintain the same addressing, you would have to
keep 80 passcodes per card, but that would no longer fit onto a
credit-card sized passcard (without a small font and a microscope :-).
 Or, have I misunderstood your design?

>> Other than that, I can't think of anything at the moment.
>>
>> I'm still working on the man pages at the moment.  I figure once we
>> have the general framework, it will be easier to incorporate changes
>> as we go.
>
> True! I've seen references to manual pages of pam module. ;) I've made
> small changes to otpasswd.1 I hope this won't cause any clash.

It'll be fine.  I've actually gotten pretty good at resolving merges.  :-)

> I hope to create a '0.5beta' package today to make it easier to check
> it for errors. I'll try to refrain from any functional changes for some
> time.

I wouldn't worry.  It's better to get this stuff done early.  And
these are still early days.

Hannes.