[Otpasswd-talk] Re: Today's Hand Grenades

[Tomasz bla Fortuna]

Dnia Sat, 9 Jan 2010 10:47:07 -0600
Hannes Beinert <address@hidden> napisał(a):

> Yes, you're right -- there really is no need I can see to introduce
> any complicated relationships between keys.

I'll try to code it up (I already have faint idea how to do it). If you
want to play with it you can create template of new config in examples/
I'd do something like this myself before coding to see if it can be
covered with some simple schema. Still I can do it, just need some
time. ;)

> > That seems nice! I guess 'ALLOW' word from keys can be dropped and
> > changed to the word-value.
> 
> Hmm.  That's true.  That would shorten up the key names, and the
> assignments would be pretty easy to read.

Mhm, it just has to be nicely redesigned. Like:
PRINTING_KEY=ALLOW|DISALLOW

Or... we can:
Allow everything rational by default and put in config
commented out entries which will disallow it.

So default config entry would look like
# PRINTING_KEY=DISALLOW

It's easier to remove # then to add 'DIS' (and remember it's DIS and
not FORBID...). I guess this also have disadvanteges. But, let's think
and correct it once and for all. ;)

> 
> >> > In DB=user, there are:
> >> > 1) Things user CAN overcome by editing file (e.g. skipping)
> >> > 2) Things utility can deny him, but he will overcome utility by
> >> > changing state file. PAM will then deny him any authentication
> >> > attempts so this is enforced somehow.
> >> >
> >> >
> >> >> 4. You know, I've been struggling with a way to talk about
> >> >> "DB=USER" and "DB=GLOBAL" -- since those "terms" are
> >> >> conceptually accurate, but they don't roll off the tongue very
> >> >> easily.  There's always "Global DB mode" and "User DB mode",
> >> >> but that is only slightly better.  One confusion is that
> >> >> "DB=GLOBAL" (or "Global DB mode") doesn't obviously *seem* to
> >> >> apply to "DB=LDAP" or "DB=MYSQL".  One thought I had was to
> >> >> call these two operational modes "User mode" and "System mode".
> >> >>  It really would be nice to have something that's a little
> >> >> easier to talk about in the manuals...  I don't know, though.
> >> >>  Thoughts?
> >> >
> >> > Renaming global to something is fine. I wasn't really happy about
> >> > this option either. I'm even not very sure about 'DB'. Maybe
> >> > 'MODE' is better?
> >> >
> >> > Still we talk about two modes of operation; one grouping global,
> >> > ldap and mysql together.
> >>
> >> I think DB=global/mysql/ldap is fine, possibly substituting
> >> 'global' for 'system'.  However, I think it's fine.
> >>
> >> The question was more about what to actually call it in the
> >> documentation?  I'm beginning to prefer "system mode" and "user
> >> mode", but I'm not sure.  The "system mode" would basically mean
> >> all types of operation which use a centralized database.
> >
> > That wording seems ok. But since you'd use 'system mode' for
> > all centralised approaches (mysql/ldap/global) I'd then keep
> > 'global' instead of 'system'. Changing might confuse someone as to
> > when we work in system-mode. Just thinking.
> 
> Absolutely, I think part of what I don't like about "global mode" is
> that the word "global" is used in the actual DB=GLOBAL setting, which
> leads to confusion.  For the purposes of the documentation, it would
> be nice to have some terms which reflect the central/non-central
> database difference.  Do you have a preference?  Do you prefer "system
> mode", and keep DB=GLOBAL, or do you prefer "global mode" while using
> DB=SYSTEM?  Or do you prefer something else?

Hm. I'm ok with DB=global and 'system-mode' naming, although it would
have a lot of merit to swap those two, I understand this. 

Generally do what you think is best.
> 
> >> >> 5. You knew I was going to ask about this, right?  What do you
> >> >> have in mind with the ALLOW_BACKWARD_SKIPPING?  That seems...
> >> >> counter-intuitive.  :-)
> >> >
> >> > Right... --skip currently works more like SETTING counter option,
> >> > as it gets the same arguments as -t and -l. So -s 3 doesn't skip
> >> > by 3 but sets counter to third passcard.
> >> >
> >> > While I think it's not particularly bad it'd be nice to be able
> >> > to say something like -s '+3' or anything...
> >>
> >> Okay...  but I still don't understand why you would *ever* allow
> >> skipping backwards?  This ability is completely contradictory to
> >> the notion of OTP, isn't it?  ;-)
> >>
> >> I think that if you skip to a passcard which is < the current
> >> passcard, it should be an error.  Don't you think?
> >
> > Skipping backwards during normal-authentication work of the system
> > for sure should end up with an error.
> >
> > I can see someone who prints some passcards and then messes -t
> > option with -s option making the system skip all what he has
> > printed. This can be root who tried to skip someones codes but
> > messed up user, or forgot --user at all. If he hasn't authenticated
> > with this passcodes there's nothing fundamentally wrong with
> > skipping back to the place he ended with. Still this can't be
> > allowed for normal (non-secure-aware) users that's why policy is 0
> > by default.
> 
> Ah, that's the use case you have in mind.  Okay, I understand, now.
> 
> Well, I think that to do this "right", one would really have to have
> two pieces of information in the user state, namely, the
> LAST_USED_PASSCODE (LUP) and NEXT_PASSCODE (NP).  The LUP is *never*
> adjusted backwards.  The NP can be skipped anywhere, as long as it is
> *always* true that NP > LUP.
> 
> This would make sense to me.  By doing it this way, LUP would only be
> updated if a passcode was used for an authentication.  As long as it
> hasn't changed, NP could be modified to any value -- forward,
> backward, whatever -- as long as NP is always greater than LUP.  The
> moment an authentication takes place, LUP is set to NP, and backing up
> is no longer possible.
> 
> My concern is really only with passcode reuse.  If there's no danger
> of passcode reuse, then I'm not even sure that there needs to be a
> policy to allow skipping.
> 
> Also, since the sysadmin can do *so* many things to screw up security,
> it's not clear to me that the superuser shouldn't be exempted from
> this, anyway.  IOW, perhaps he should be able to change NP such that
> NP <= LUP.  But only with a warning.  And again, I think that LUP
> should only be changed after an authentication.
> 
> Is this silly?
I guess it's true. But I really doubt it's worth implementing. It's just
better to remove backward skipping and omit bigger
state/policies/options mess. We can make it less lenient, and more
secure without much hassle like this:
1) Remove policy at all. User won't be able to skip backwards NEVER.
(Unless he uses DB=user).
2) Allow admin to skip backward but not only with warning, but with
warning + yes/no question regarding if he really things so. Stating
this question might only not be trivial (locking problem).

Or remove option completely. If admin really things he known what he is
doing he can edit state. (this can create many locking problems though,
which makes me think... should we create 'viotpw' tool similar to
'vipw'?)


I'll push gettext() changes soon.


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

signature.asc
Description: PGP signature