Re: Spoofing as the postmaster
От | Mark Mielke |
---|---|
Тема | Re: Spoofing as the postmaster |
Дата | |
Msg-id | 47757B37.9040609@mark.mielke.cc обсуждение исходный текст |
Ответ на | Re: Spoofing as the postmaster (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Spoofing as the postmaster
|
Список | pgsql-hackers |
Magnus Hagander wrote: <blockquote cite="mid:477578F0.2010303@hagander.net" type="cite"><pre wrap="">Mark Mielke wrote:</pre><blockquote type="cite"><br /><pre wrap="">I have done this for my own application before. Although the clientand server use standard TLS 1.0 to speak to each other with a required authentication of RSA 1024-bit and a required encryption of AES 128-bit, it still requires that passwords sent from the client to the server are RSA encrypted using the server public certificate, making it impossible for anybody except for the legitimate server to see the password. One benefit of this is that the password itself can be '\0'd out as soon as we have RSA encrypted it, and things like a core dump of the client have a lower chance of including the password in plain text. </pre></blockquote><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><br /> Users of this product don't have keys - theyhave passwords. The username/password is for per-user authentication. The username defines the access level. Many userswill use the same client. The client does have its own private RSA key and public certificate, however, this grantsentry to the system. Password login is still required by the users of the client.<br /><br /><blockquote cite="mid:477578F0.2010303@hagander.net"type="cite"><blockquote type="cite"><pre wrap="">At what point does prudence becomeparanoia? I don't know. In my case, I felt 128-bit encryption was insufficient for protecting the passwords in my application. 256-bit encryption would have been sufficient, but that cannot yet be safely exported from the US to the countries I required. </pre></blockquote><pre wrap="">How do you protectthe certificate store on the client? Or the binary that ends up prompting for the password on the client</pre></blockquote> The certificate on the client grants access to thesystem. 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 stillneed to login to the computer once you get in.<br /><br /> As for protecting the binary that prompts for a passwordon the client - I didn't bother with this, although Java does allow for signed jar files that would allow the userto be assured that the client is legitimate. There are always loops though, just because the client is legitimate doesn'tmean 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.<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 по дате отправления: