Re: Design Considerations for New Authentication Methods

From: mark(at)mark(dot)mielke(dot)cc
To: Magnus Hagander <mha(at)sollentuna(dot)net>
Cc: Richard Troy <rtroy(at)ScienceTools(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, "Henry B(dot) Hotz" <hotz(at)jpl(dot)nasa(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Design Considerations for New Authentication Methods
Date: 2006-11-03 07:56:06
Message-ID: 20061103075606.GA32097@mark.mielke.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 03, 2006 at 08:05:05AM +0100, Magnus Hagander wrote:
> > > The same could apply to SSL cert based authentication, for users
> > > connecting from machines outside of my realm. Once you have
> > "unlocked"
> > > the certificate, you can authenticate any number of times to any
> > > number of services that will accept this certificate
> > *without* having
> > > to re-enter your password.
> > Why would you need to unlock it? SSL certificate is
> > effectively a password stored in a file of length 1024 bits
> > or whatever.
> Because if someone can access this file, I don't want them to
> automticlly "be me". Say this file is on my smartcard - I most certainly
> want a PIN code before it logs me in.
> Now, if I trust my local machine reasonably well, this "unlock" can
> equal the "local login". But there's still an unlock sequence.

Yes - local login. I didn't think of it in that context, as I think
more of batch processes, or servers accessing the database. A person
accessing just doesn't seem significant to me. It's more of a special
case. :-)

I prefer to use PostgreSQL with a local socket, and passing of UNIX
credentials over the socket. If you can login to the account, you
can access all of the scripts owned by that account that have a
PostgreSQL username/password embedded within them anyways - so why
embed at all? Obviously, for remote database access, or for any system
with load sharing across systems accessing the same database, this
doesn't work too well and an alternative such as SSL certificates
becomes desirables. The effect is the same, though.

> > I don't understand the OTP part. Single signon is only a convenience.
> > Ability to resume a session (provided by SSL) or ability to
> > login using a smaller authentication token than a certificate
> > can be used to provide performance improvement.
> OTP can certainly be a *lot* more secure, when used in the right way.
> This of course rquires you use a two-factor system such as a token based
> key or challenge/response system.

Not sure why it would be more secure by using a smaller key on second
entry. Sure the smaller key times out, but effectively you now have
two or more keys instead of one. :-)

> And it's not just a convenience. SSL reusme session doesn't work if the
> first login is to my fileserver, the second to my maliserver and the
> third to my database server. I would then require three separate OTP
> logins.

*nod*

> Since they would normally have a time-window, it will also
> noticably slow down the process since I'd have to wait for a new key
> before accessing each resource.

This presumes that you use a key system. SSL certificate is adequate
on its own for many uses... :-)

> > The benefit to kerberos, from my perspective, is that it
> > already exists, and is widely used.
> Yes, that is a huge benefit.

Ignoring my liking of SSL certificates, and my defense of them, I agree
it is a huge benefit to support Kerberos for these reasons.

> > My own system at home uses RSA keys or
> > SSH entry. I don't bother with passwords anymore. If they can
> > access my password, they can access my certificate. If they
> > can access my certificate, they can access my password. Dual
> > authentication models work better with very different
> > systems. For example, a USB key or digital display that I
> > possess, and a password that I know or have stored in a file.
> Well, you know how to deal with passwords and authentication. Most users
> don't. Therefor using things like smartcard+PIN can *both* increase
> security *and* make things easier for them. To make it work in reality,
> that means you need to support whatever infrastructure standard other
> systems use, and that's most commonly Kerberos today. And second most
> common I would beleive is SSL/TLS certs.

*nod*

I agree.

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2006-11-03 08:06:55 Re: "recovering prepared transaction" after serverrestart message
Previous Message Magnus Hagander 2006-11-03 07:16:23 Re: Design Considerations for New Authentication Methods