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

[Hannes Beinert]

On Tue, Dec 22, 2009 at 16:33, Luke Faraone <address@hidden> wrote:
> On Tue, Dec 22, 2009 at 17:21, Hannes Beinert <address@hidden> wrote:
>>
>>  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.
>
> That makes sense. OTOH, if a user wants to intentionally compromise the
> security of his login, he can anyway by a number of easier means. I'm not
> opposed to a central database, I just think that ad-hoc should be the
> default.

I certainly think it would be nice to have as an option.  However,
honestly, I can't think of many advantages.  If PPP could be installed
by the user without any sysadmin intervention or cooperation, such as
in a situation where one is just an individual user on a large system
with sysadmins "who can't be bothered", then this would be a really
useful option.  However, to use PPP for login the system PAM stacks
need to be modified.

As it stands, the only situation I can see is where a user wants to
use a OTP facility in a custom-PAM-enabled user application.  For
example, a MySQL client, or whatever.  In that case no system-level
modifications need to be made, and all files should be local to the
user.

>> 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.
>
> And that'd also be vulnerable to replay attacks with the signatures, unless
> again something was kept in a global database.

Yeah, I was going to say that a cryptographic hash could also be used
-- and would probably be better -- but the hashes would need to be
stored in a global database.  So, somehow, the DB keeps rearing its
head.

> Apologies for currently being unable to contribute any code. I'm in the
> process of learning C and do not yet feel that I'd be able to contribute
> anything robust or useful at this time.

Well, Tomasz is the only dev, currently.  I'm just the peanut gallery.  ;-)

Hannes.