Re: Spoofing as the postmaster

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>