Re: [PATCH] One time password

[Mark D. Baushke]

Derek Robert Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> 
> |Hi Brian,
> |
> |I am somewhat ambivalent about your patch.
> |
> |It is not clear to me how shell scripts might be
> |able to pass an appropriate one-time-password to
> |cvs.
> 
> Well, they shouldn't be able to, really.  OTPs usually require a human
> with a little device that they can punch the PAM prompt into and which
> then supplies a new, use-once  password.

Sure, some do. Others (eg, S/Key) are algorithmic and could be scripted
if the client is a secure environment. This is not always the case, but
it may be possible or true for some clients of a cvs server that is
moving to NULL_PASSWORD :pserver: authentication.

> |Is this lack is why there is no sanity.sh
> |infrastructure to deal with this new feature?
> |
> |If it is only possible to read from /dev/tty, then
> |perhaps that fact also needs to be included in the
> |documentation?
> 
> I think this is the way to go with it.

I think I'd still like another input mechanism to be available...

> |For myself, I might like to see it possible to use
> |something like the ssh-askpass program such as is
> |used by OpenSSH when there is a need to ask the
> |user for a password, but /dev/tty is not a
> |controlling terminal device?
> 
> 
> Ooh, I'm afraid of getting involved with GUI plugins at this point.  Do
> you have an architecture in mind?

Actually, the ssh-askpass mechanism does not need to be a GUI plugin. It
may also be an unattended agent... although that is not the most typical
configuration.

To be honest, I have not thought thru all of the implications yet of a
ssh-askpass mechanism. It was late when I responded...

As has been already established, I would rather see passwords handled
externally and that cvs would never need to prompt for them and that
when they are sent over the wire, they are not able to be trivial
descrambled... in other words, I am not a fan of :pserver: at all. The
addition of PAM support means that the problem is not getting any
cleaner. I could envision users of PAM authentication dropping support
for a scrambled password just so the password was not stored in the
.cvspass file... possibly as a configuration option for the server.

That said, a new feature that ties prompting for a password soley to the
keyboard seems undesirable to me.

Given that even PGP allows the user to have the passphrase read from a
socket, I suspect that some kind of non-tty input is desirable to make
this feature as flexible as may be desired.

For example, gpg has the option:

       --passphrase-fd n
                 Read the passphrase from file descriptor  n.  If
                 you  use  0  for  n, the passphrase will be read
                 from stdin.     This can only be  used  if  only
                 one  passphrase  is  supplied.   Don't  use this
                 option if you can avoid it.

I would think that the NULL_PASSWORD mechanism might be able to do
something similar. Of course, the password prompt would have to be
to some place that could potentially be read externally, such as
STDERR.

Having such a hook is not always needed, but having it might make this
feature more useful. And the possibility of an administrator mandating
no srambled passwords be saved seems plausable if the transport for the
passwords between the client and server could ever be encrypted with
something like a simple Diffie-Helman key exchange or as complex as a
full TLS credential exchange to verify that the server is not a
man-in-the-middle.

> What sort of cases were you attempting to handle?  

Well, among others, automated scripts that checkout the latest versions
of a module or sweep the latest changes into a module. Granted that most
of these would be using some kind of SSH credentials or existing
.cvspass scrambled passwords for login, still if NULL_PASSWORD becomes
more popular, they may need to be updated.

> CVS wrapper scripts?

Yes, cvs 'wrapper scripts' as well, or at least 'make' commands that
might use cvs. I have seem a number of setups that issue multiple cvs
commands for the user as a part of the 'build' process for their
software (typically doing 'cvs update' in multiple sub-directories to
potentially multiple repositories).

> Individual users and sysadmins would still be free to set up SSH if they
> prefer.

Sure. I was just trying to figure out if it was possible to have a
slightly stronger network experience that actually uses this new
feature.

> |I do understand the desire to get prompted by
> |a one-time-password, but wonder if :ext: using
> |"ssh" as a transport does not already solve this
> |problem more efficiently?
> 
> 
> Maybe, but despite my personal preference for SSH as well, some users
> still find various reasons to object to this setup.

Yes, I understand.

> |I believe I would like to see either Derek or Larry
> |give it a thumbs-up or down.
> 
> 
> I probably shouldn't give it a thumbs-down yet, since I suggested the
> patch in the first place.  :)

Okay. It actually is a good idea that a one-time-password be able to be
used given that the password is going across the wire in the clear.

All I am suggesting is that consideration be given to an alternative to
/dev/tty for reading that password.

> I'm open to discussion, but thought that given that we were adding PAM
> support in the first place, it would be worthwhile to support OTP.  At
> the least, it would enable sysadmins to sidestep the almost-clear-pass
> security problem if they wish to.

Okay, I can understand that reasoning. I hope that my suggestions are
also able to be understood.

For my part, I think it might want another paragraph of documentation
discussing why reading from either the /dev/tty or a named pipe or open
file descriptor is not a good idea for this new feature.

The documentation is also not 100% clear that the server is preparing a
message for the client that is to be displayed as a part of the password
prompt... It would be well to know exactly how the new server protocol
works and interoprates with older clients and servers so that when folks
run into problems it will be more clear what is wrong.

        Thanks,
        -- Mark