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

[Tomasz bla Fortuna]

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

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

No worries, change whatever you think is appropriate. I always prefer
to write something down than to forget it. Once it's written it can
always be corrected. ;-) People learning slavic languages (i.e. Polish)
usually have biggest problem with declination at first and just use
nominative all time. 

(Off Topic)
Also I was surprised that english language doesn't allow much
'softening' of nouns once. You say tree, small tree (or sapling, but
that is different word), smaller tree, smallest tree in polish you may
say drzewo, drzewko, drzeweczko, drzeweńko (which starts to sound a bit
exaggerated, but it still correctly understandable). Or 'sun': Słońce,
słonko, słoneczko. 'Road': Droga, dróżka, dróżeczka. English doesn't
offer much here, but, well, works. 


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

We will see what can be done. (Few weeks ago I wouldn't say we'll have
a working global state with policies now).

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

Okey, that's right -- it's always better to leave user (or admin in
that case) option. That still as I think about it requires quite lot of
options. SPass might be required to authenticate, or used 
for additional options (and then it musn't be entered on not-trusted
machines very often).

Simple passcode prompt doesn't inform attacker that the static password
is required at all -- and that might be interesting.

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

Changing this would be better now than in future. I've decided on
CRR[card] because it's easy to detect (the only which starts with
letter). I guess I can change it more/less easily. I dislike brackets
mostly because of '' required on some shells. It's ok for bash but not
for zsh. If {} would be allowed in paralell then I could drop '' on zsh
and use {}. But that's also kind of unnecessary code complication.

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

It changes current address. Say I'm at 2C [3] with codelength-4, that's
0x95 passcode. If I change to use codelength-16 otpasswd will change
current prompt to 5B [8] (which is 0x95 passcode but on the new
passcards which hold only 2*10 passcodes instead of 7*10).

Changing this option invalidates printed passcards for sure, but can
always be changed back if somebody doesn't like it. With db=user user
always could do it himself and even it was impossible to pass -f along
with -k (this works since yesterday only) so it had to work this way.
Currently this could be disallowed, but requires regenerating the key
if somebody missed -f option during generation.

I don't see problem really, it can probably confuse users somehow but
then I'd rather choose to print a warning instead of forbidding it.
Still forbiding now is possible.

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

signature.asc
Description: PGP signature