The problem with forcing authentication is that an auth-unaware client
connecting to a legitimate postmaster would have its connections
refused. That same client would have its connections accepted by an
impostor postmaster. Thus, there is no way to stop impostor postmasters
from carrying out these attacks on auth-unaware clients.
The proper solution, as I see it, would be to have an authentication
system in the postmaster that was not enforced. If the client requests
authentication, postmaster will provide it, if not, then postmaster will
connect normally without it. This would not result in *any* change in
the default behavior of postmaster, and as far as users who don't want
to use it are concerned, they don't even need to bother to turn it off
(assuming that having it turned on does not consume extra resources and
I don't think having an unused authentication mechanism sitting in the
postmaster connection establishment routine would).
This does not appear to result in greater security, however it does. It
allows DBAs who suspect that they are likely going to be the target of
these attacks to deploy authentication procedures in their client
packages. This could be a modification to their applications, or
whatever steps are necessary to mandate authenticated connections within
their organization.
There is no point forcing some auth mechanism within postmaster, as
attackers would simply catch users using software that did not require
the server to auth before sending passwords. For this reason it is not
postmaster's responsibility to check that unknown clients do not connect
to impostors, it is postmaster's responsibility however to authenticate
itself, if the client asks for it. So the onus (rightfully in my
opinion) falls upon network administrators / DBAs to ensure that all of
their users are using auth-enabled client packages which will not allow
connections to be established with a postmaster until authentication has
passed, and disallow the use of other client software to connect to
postmaster.
In my view, this puts the security responsibility where it rightfully
belongs *and* maintains a non-breaking of client packages in the wild.
Making a server or anything that *requires* auth and disallows
non-authed clients is pointless, as there is nothing stopping attackers
from setting up an auth-disabled impostor and waiting for someone to
just connect using psql or some other vanilla connection method. The
onus really ought to be with the administrators who give their users the
software they use to connect to ensure that the software they use
adheres to the relevant security policy, in the same way that its their
responsibility to ensure that the client software does not contain
keyloggers and other such trashware.
In the web world, it is the client's responsibility to ensure that they
check the SSL cert and don't do their banking at
www.bankofamerica.hax0r.ru and there is nothing that the real banking
site can do to stop them using their malware infested PC to connect to
the phishing site. They can only provide a site that provides
authentication. This is analogous to postmaster: It is only the
responsibility of postmaster to provide the option of authentication, it
is the client's responsibility to know if they should use it, and if so,
to ensure they do so properly.
Regards,
- MrNaz.com
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
