"Password validation services" -- how can we avoid creating more of them?

Thu Dec 28 19:32:38 PST 2006

On Thu, Dec 28, 2006 at 04:57:33PM -0800, Jason Dusek wrote:
> ...
> Public key authentication has its own problems, doesn't it?

I don't know of anything that has no problems.  The issue is how
one establishes the cost/benefit tradeoff.  In the case in point,
my concern is that allowing authentication mechanisms that rely
strictly on a login/password correspondence  are effectively services
that may be abused by folks to set up processes to determine passwords
for known logins (gleaned, e.g., from email addresses) to be
determined -- via brute force, if nothing else.  Allowing such
requests from untrusted sources is an invitation to thiis particular
form of abuse; I seek ways to mitigate this effect.

> If you want to distribute keys infrequently than you have the
> revocation list problem. If you distribute keys frequently, then
> you've got to secure that process and you're basically back to
> square one. Kerberos' combination of keys and passwords does seem
> like a good compromise, though.

My recollection is that there  are no authentication mechanisms
specified by Kerbeos per se.  If that's correct -- I don't recall, and
the copy of the O'Reilly "Kerberos" book I've been reading is at work,
which is a place where I am currently not -- I invite you to clarify
your meaning.

> ...
> >Were it up to me, I'd just set up SSH servers to only use public key
> >authentication, and have folks access everything via SSH tunnels.
> 
> Well, it's reasonable to use keys when they are available -- keys
> should be preferred, and hopefully the majority of your users will
> have them; but password authentication helps to cover those
> authentication corner cases that crop up every so often (a staff
> member is on a trip, their laptop dies, they find an internet kiosk at
> the public library...)

Hmmm... it seems that I failed to communicate my concern.

At least for OpenSSH, I do not know of a way to (only) permit public
key authentication for some users, while allowing password
authentication for others.  If this assertion is correct, allowing *any*
password authentication for a given machine exposes *every* user with an
account on that machine to precisely the type of password-acquisition
abuse that I'm trying to avoid.

Yes, I understand that keys are inconnvenient at times.  A reasonable
alternative might be some other 2-factor authentication mechanism, such
as requiring (first) a SecureID fob, then a password (something you have
+ something you know).

But in the mean time -- and *this* was the original point of my note --
there are other services, such as IMAPS or HTTPS which encrypt their
traffic (which is good) and requiree authentication to use them (which
is also good), but for which the common (only?) authentication
mecchanisms are such single-factor authenticators as passwords, so
opening these services up to the Internet provides a service to
facilitate the inappropriate acquisition of authenticastion information
via those services.  And at least where I work, my colleagues & I are
expected to make these available to an ever-widening set of clients.

Is there some way to usee 2-factor authentication mechanisms for *all*
remote access?  Not just SSH; that works fine:  what about HTTPS?
IMAPS?  Any others?

Thanks.

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 1999.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.baylisa.org/pipermail/baylisa/attachments/20061228/f86787ba/attachment.bin>