On Thu, Nov 02, 2006 at 10:48:29PM +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.

> This is both a convenience for the user, and a requirement if you use
> OTPs.

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.

If the requirement is that no password is provided, password + SSL
certificate is not an improvement. Any token based authentication system
should allow for the token to become invalid at any time, and require
re-authentication using the primary mechanism.

The benefit to kerberos, from my perspective, is that it already exists,
and is widely used.

I prefer SSL certificates alone myself. All of my db passwords are randomly
generated anyways, and a 1024-bit randomly generated password is better than
a 64-bit password picked by a person at a keyboard. Having both isn't an
improvement I think. 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.

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 bind them...

http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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


> > This is both a convenience for the user, and a requirement
> if you use
> > OTPs.
>
> 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.

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


> The benefit to kerberos, from my perspective, is that it
> already exists, and is widely used.

Yes, that is a huge benefit.


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

//Magnus



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 bind them...

http://mark.mielke.cc/


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

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