Re: [Otpasswd-talk] Using OTP to kind of fix MITM.

[Hannes Beinert]

Luke,

On Tue, Dec 22, 2009 at 15:50, Luke Faraone <address@hidden> wrote:
> On Tue, Dec 22, 2009 at 12:01, Tomasz bla Fortuna <address@hidden> wrote:
>>
>> This can be also a pain taking into account that
>> otpasswd will have to be SUID to work with global database. I'd like to
>> implement this by 1.0, but for now there're still some things to do. ;)
>
> Huh, SUID?   Why does there need to be a global database? Can't we
> just put it in ~/.otpasswd chmodded properly, like we do with SSH keys?

The reasoning for including the ability to use a global database is
something like this:

Suppose the sysadmin makes a policy decision to allow SSH logins.
There are two cases.  First, SSH is optional, in which case the system
security is no worse than the standard login.  Second, SSH is
required, in which case system security is enhanced.  If the user
screws up the SSH state files, then in all likelihood the ability to
do SSH logins for that user will be disabled.  In the first case
above, again, system security is no worse than the standard login.  In
the second case, since the user can't login at all, that clueless user
has just made the system disproportionately more secure.  ;-)

Now, by comparison, let's look at PPP.  If the sysadmin decides to use
PPP as an option for the user, then system security is again no worse
than the standard login.  In this case, it makes no difference where
the state files are kept, since if the user breaks or undermines PPP
in some fashion, system security will be no worse than the standard
login.  In the second case, however, the sysadmin wants to enhance
system security by requiring PPP usage.  If the user completely breaks
PPP for him/herself, then it's true that system security will be
enhanced because logins for that user would be disabled.  OTOH, if the
user modifies the state files to use poor sequence keys (by whatever
definition you choose to apply), or rolls back the counter for the
"current passcode" which would enable a replay attack, the user has
actually lessened system security.  By keeping the files in a global
system-controlled database this latter vulnerability could be
mitigated.

It has been discussed that the state files could be kept in the user's
directory hierarchy, but be cryptographically signed with a private
key known only to the system.  This obviously also has
vulnerabilities, in addition to introducing the headache of doing a
key change.

Tomasz also suggested that if otpasswd had the ability to use a global
database, it might make it easier to include LDAP functionality at
some point.  The idea of being able to use a single set of passcards
for any login to a set of machines could be very appealing.

Hannes.