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: