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

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

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.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to