> > > > 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
