Re: Design Considerations for New Authentication Methods

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