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

From Mark Mielke
Subject Re: Spoofing as the postmaster
Date
Msg-id 47766478.2020902@mark.mielke.cc
Whole thread Raw
In response to Re: Spoofing as the postmaster  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander wrote: <blockquote cite="mid:47763626.6010301@hagander.net" type="cite"><pre wrap="">Mark Mielke
wrote:</pre><blockquote type="cite"><blockquote type="cite"><pre wrap="">Why are you even using a password in this
case,and not just key-based
 
auth? Wouldn't that be even easier and more secure?     </pre></blockquote><pre wrap="">Users of this product don't
havekeys - they have passwords. The
 
username/password is for per-user authentication. The username defines
the access level. Many users will use the same client. The client does
have its own private RSA key and public certificate, however, this
grants entry to the system. Password login is still required by the
users of the client.   </pre></blockquote><pre wrap="">And you have one private key *per client*? That's an
interesting
approach - and actually how pg will work if you enable client cert
checking :-) </pre></blockquote> Yep.<br /><br /><blockquote cite="mid:47763626.6010301@hagander.net" type="cite"><pre
wrap="">
It's probably about as far as you can get as long as you use passwords.
If you want something that's really secure, you just have to give up
using passwords. Solutions like one-time passwords from a token or
certificates on a smartcard are what people use then :-) </pre></blockquote> Yes. Pseudo-random number generator on an
LCDdisplay that changes every 60 seconds, or one of those government satellite-based systems. :-)<br /><br /> Even
still,it's often two forms of authentication. With the SecureID cards, the number proves you have the physical card on
yourpossession, and the password proves you have access to the person's brain (or piece of paper that they stupidly
wrotetheir password on :-) ). Most of these systems are not necessarily effective against kidnapping the person and
threateningto kill them. However, they are very effective against random hackers on the Internet who are doing trial
anderror or some other approach. By denying entry BEFORE the password is provided, they are unable to guess passwords
andget lucky.<br /><br /><blockquote cite="mid:47763626.6010301@hagander.net" type="cite"><blockquote type="cite"><pre
wrap="">Thecertificate on the client grants access to the system. It does not
 
grant access to the resources on the system. Two-level authentication
with mandatory server authentication. You see similar things in physical
security instances. A security badge lets you in the door - but you
still need to login to the computer once you get in.

As for protecting the binary that prompts for a password on the client -
I didn't bother with this, although Java does allow for signed jar files
that would allow the user to be assured that the client is legitimate.   </pre></blockquote><pre wrap="">Only as long
asyou can trust the JRE... And the OS... (yeah, reaching,
 
but still goes to prove the point that the system *cannot* be secure if
people can chance your client code/machine. It can be secure from a
server or network POV, but not froma client one) </pre></blockquote> Correct. I believe this is why I didn't bother. I
sawvalue to using better than 128-bit AES for the password (as per US export control regulations), but not for the data
(thedata was primarily a list of privileged write requests), and I saw value to making the password unreadable as soon
aspossible (the client might be long running, but it turns the password into RSA encrypted data soon after you hit
ENTER,and reuses this for the length of the session if the password is required again). I didn't see value to
protectingthe client.<br /><br /><blockquote cite="mid:47763626.6010301@hagander.net" type="cite"><blockquote
type="cite"><prewrap="">There are always loops though, just because the client is legitimate
 
doesn't mean that the keyboard is, and so on. You end up putting in
enough effort to mitigate the risk. The risk always exists, but through
clever, cryptographic, or obfuscatory measures, the risk can be greatly
reduced.   </pre></blockquote><pre wrap="">Right</pre></blockquote> If it was an easy problem, somebody would have
solvedit once and for all, and the CIA would be out of business... :-)<br /><br /> Cheers,<br /> mark<br /><br /><pre
class="moz-signature"cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>

pgsql-hackers by date:

Previous
From: "D'Arcy J.M. Cain"
Date:
Subject: Re: Spoofing as the postmaster
Next
From: Andrew Dunstan
Date:
Subject: Re: Spoofing as the postmaster