Re: Spoofing as the postmaster - Mailing list pgsql-hackers

Andrew Sullivan wrote:
> On Fri, Dec 28, 2007 at 07:48:22AM -0800, Trevor Talbot wrote:
>> I don't follow. What are banks doing on the web now to force clients
>> to authenticate them, and how is it any different from the model of
>> training users to check the SSL certificate?
> 
> Some banks (mostly Swiss and German, from what I've seen) are requiring
> two-token authentication, and that second "token" is really the way that the
> client authenticates the server: when you "install" your banking
> application, you're really installing the keys you need to authenticate the
> server and for the server to authenticate you.

Most actually secure banks would be using standalone tokens, and not
something that runs on your local machine and can easily be compromised.
There needs to be air between the token and the computer. The exact
difference in security is always debatable, but "air gap" tokens is
what's been used for most banks here for many years - in many cases
since they first started doing internet banking 10+ years ago.

But. That's for authenticating the *client*. Authenticating the server
in the end requires you to trust the security of the client machine, and
requiring special applications for that just makes it worse :-( And in
the end, the only thing they really do is implement the browser the way
it should've been implemented in the first place. The bottom line is
still that the security against that has to happen on the client side.

We could make it so that we *require* the root certificate to be present
on the client and make the check, and simply refuse to connect without
it. But my guess is that it'll just increase the bar for SSL adoption at
all, whilst most people will find some insecure way to get the root key
over there anyway. Unless we want to start shipping our own batch of
trusted roots, and only support paid-for certificates or something...


>> There's a fundamental problem that you can't make someone else do
>> authentication if they don't want to, and that's exactly the situation
>> clients are in. 
> 
> Right, but you can train users to expect authentication of the server.  One
> way to do that is to require them to use an intrusive enough system that
> they end up learning what to look for in a phish attack.  That said, I tend
> to agree with you: if we had dnssec everywhere today, it's totally unclear
> to me what client applications would do in the event they got a "bogus"
> resolution.

Well, we all know how well the big warning boxes in the web browsers
work... You can't really trust the user to make such a decision, in the
end. You can get to a point, but not all the way by far.

But what you can do is that as an administrator, you can require these
checks. If you only allow connections from machines that are trusted,
and you make sure those are configured to require verification of the
server cert, then you're safe.

//Magnus