Re: Design Considerations for New Authentication Methods - Mailing list pgsql-hackers
From | mark@mark.mielke.cc |
---|---|
Subject | Re: Design Considerations for New Authentication Methods |
Date | |
Msg-id | 20061103075606.GA32097@mark.mielke.cc Whole thread Raw |
In response to | Re: Design Considerations for New Authentication Methods ("Magnus Hagander" <mha@sollentuna.net>) |
Responses |
Re: Design Considerations for New Authentication Methods
|
List | 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@mielke.cc / markm@ncf.ca / markm@nortel.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 bindthem... http://mark.mielke.cc/
pgsql-hackers by date: