Re: Design Considerations for New Authentication Methods - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Design Considerations for New Authentication Methods
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA0FCEE@algol.sollentuna.se
Whole thread Raw
In response to Re: Design Considerations for New Authentication Methods  (mark@mark.mielke.cc)
Responses Re: Design Considerations for New Authentication Methods
List pgsql-hackers
> > 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.


> > This is both a convenience for the user, and a requirement
> if you use
> > OTPs.
>
> 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.

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. 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.


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

Yes, that is a huge benefit.


> 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.

//Magnus




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: "recovering prepared transaction" after server restart message
Next
From: "Magnus Hagander"
Date:
Subject: Re: Design Considerations for New Authentication Methods