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

[Tomasz bla Fortuna]

Dnia Sun, 3 Jan 2010 16:05:30 -0600
Hannes Beinert <address@hidden> napisał(a):

> Hi
> On Sun, Jan 3, 2010 at 12:36, Tomasz bla Fortuna <address@hidden> wrote:
> >
> > spass, channel_Time, failures, recent_failures are not fully
> > implemented but have you got any idea what should be added today so
> > we won't later break compatibility when changing it? Any ideas
> > welcome. After the next "stable version" I guess I should stop a
> > bit with this state changes.
> 
> I saw that you've been working hard!  :-)
> 
> 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.

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

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

> 
> 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]: <...>

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.

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


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.

Failures track is one thing I'll have to do and static passwords -
second.

Cheers, ;-)
-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

signature.asc
Description: PGP signature