Re: [Otpasswd-talk] Re: Bug#562968: ITP: otpasswd -- one-time passwords implementation for PAM

[Hannes Beinert]

Hi Luke,

On Tue, Dec 29, 2009 at 15:49, Luke Faraone <address@hidden> wrote:
> On Tue, Dec 29, 2009 at 12:22, The Fungi <address@hidden> wrote:
>>
>> On Tue, Dec 29, 2009 at 12:05:20PM -0500, Luke Faraone wrote:
>> > Unlike OPIE, otpasswd uses modern hashing algotrithms and supports
>> > offline
>> > / out-of-band use.
>>
>> A compare/contrast with the libpam-otpw package would also be
>> interesting.

Ah, there's always an academic in the crowd (:-).  I should've
expected this question, as it is really quite valid.

> That said, I have not studied OTPW nor the security of otpasswd closely, and
> would advise anybody making a choice between the two to perform their own
> research.

I think your reply was great, and this last section is obviously
always true when it comes to security issues.

Assuming that the 'cause I like it better so there neener-neener
argument doesn't fly with the DD/UD/MOTU (;-), here's a quickly
compiled list of comments regarding the differences between OTPW and
OTPasswd.  Please don't forward any of this before Tomasz has a chance
to review it.

OTPW ==> their package
OTPasswd ==> our package

In a nutshell, OTPW is a nicely done, well-documented, and
well-considered package.  Generally speaking, both OTPW and OTPasswd
are intended to address the same concern.  However, OTPW and OTPasswd
exhibit slightly different design goals, and as such have different
strengths and limitations.

1.  OTPasswd does not require system-wide state information.  As an
option, it can be configured to save state information in a user's
home directory.  This eliminates the need for any SUID/SGID privilege
escalations.

2.  When user-state information is kept under user control, security
policy cannot be enforced since the user is able to modify or remove
the state information.  In the case of both OTPW and OTPasswd,
modification of user state information could lead to the reuse of OTP,
thereby weakening the system.  If user state information is deleted
entirely, both OTPW and OTPasswd are faced with similar choices in
terms of the default policy -- either to unconditionally allow or deny
authentication.  When OTPasswd operates in a mode to keep the state
information under system control, both of these concerns are mitigated
or eliminated entirely.  Note that in no case will OTPasswd ever
require SUID root privilege.

3.  OTPasswd is is (optionally) compatible with the well-documented
and well-discussed PPPv3 specification.  This allows it to interact
with a number of independently developed PPPv3 compatible
applications, specifically those intended to operate on mobile devices
and thus function in a similar manner to an RSA security token.  See
http://www.grc.com/ppp/software.htm for a list of software currently
available.  To the best of my knowledge, no such capability exists for
OTPW.

4.  OTPasswd includes the ability to send passwords using an
out-of-band channel, such as, but not limited to SMS.  The interface
with OOB channels can be configured via scripting and is thus very
flexible.  OTPW has no such capability.

5.  OTPasswd has (or will have) the capability of great flexibility in
printing "passcards" of user passwords (passcodes) since the layout
will be generated through the use of scripting.  This flexibility
allows users to select font sizes for easier readability, custom
layouts, and could even potentially allow passcards in Braille.  OTPW
has no such capability.

6.  OTPW needs only a single password prompt, since it combines a
static prefix password with the OTP component.  OTPasswd requires an
additional prompt for the OTP component.  IOW, OTPW combines the
"first factor" (what you now) along with the "second factor" (what you
have).  The increased modularity of breaking these two factors apart
into separate functionality could considered to be an advantage.  The
OTPasswd PAM module could easily be hooked into any PAM stack to add
*just* OTP capability, without having to use a repetitious static
prefix.

7.  OTPW uses an interesting strategy to address what they call the
Race-For-the-Last-Key attack by requiring a concurrent login session
to use a "triple" OTP.  While this is clever, this could potentially
lead to an (albeit unlikely) DoS attack through OTP depletion.  A more
serious consequence of this strategy is that an attacker would gain
knowledge on every failed attempt at a "triple" OTP login attempt.
Again, though, the probability of the success of this type of attack
is quite low.  OTPasswd has a much more predictable method of
consuming OTP, and the consumption of excessive OTP clearly signal an
attacker who is already aware of the user's login password.

8.  OTPasswd allows the use of a user-selected alphabet for password
entry.  This allows a user to select an alphabet which most suits
his/her language, keyboard, preference, or accessibility needs.  OTPW
appears to restrict a user to a modified base-64 encoding.

9.  Due to the way in which OTPasswd computes passwords using the
password entry alphabet, the information density (password entropy)
per typed character can be much higher than with OTPW, which uses a
modified base-64 encoding.  This requires that fewer characters be
typed for the same level of security, making over-the-shoulder attacks
more difficult.

10.  OTPW uses a pre-computed list of one-time passwords.  This makes
password depletion a very real possibility.  OTPasswd, OTOH, generates
passwords on-the-fly using an algorithm coupled with information from
the user's state information.  As a result, key depletion is a
practical impossibility.  Even if the user runs out of passwords
on-hand, an
endless stream may still be send via some user-configured out-of-band channel.

11.  OTPW is capable of providing OTP capability without any
host-based secrets.  OTPasswd is not currently capable of doing this.

These are just some thoughts.  Let the pie-throwing begin.  :-)

Hannes.