From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | <mark(at)mark(dot)mielke(dot)cc> |
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 09:38:32 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCEA3589B@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
>
> 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. :-)
Heh. Depends on your scenario, I suppose. There are loads of legacy apps
out there that are just fat-client-directly-to-database, and we like to
run those on pg as well...
> 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?
When it's a local user, that's what I use as well. (Except it does prove
troublesome with interfaces that don't support UNIX sockets (for
example, the mono provider doesn't. I don't think the JDBC one does
either))
> > > 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. :-)
You use the smaller key *the first time*, not the second one. Why?
Because it's easier.
Sure, if you can stick a cert on a smartcard, then you can have the big
key *and* proper two-factor. And in fact in at least Windows, if you do
smartcard login it will integrate fine with both SChanenl (SSL) and
Kerberos.
The SSL cert needs to be in a trusted store of some kind. It can be a
smartcard (easy), or it can be a password protected store (not so easy,
at least not if you want to have a good password).
> > 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... :-)
Sure, but it's not two-factor unless you use smartcards. If you do
smartcards, SSL certificates are very good.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas ADI SD | 2006-11-03 10:40:14 | Re: [PATCHES] WAL logging freezing |
Previous Message | Oleg Bartunov | 2006-11-03 08:54:05 | Re: [HACKERS] Index greater than 8k |