Re: Spoofing as the postmaster

Mark Mielke wrote:
> Magnus Hagander wrote:
>> Mark Mielke wrote:
>>
>>>
>>> I have done this for my own application before. Although the client and
>>> 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.
>>>
>>
>> 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?
>>
>
> Users of this product don't have keys - 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.

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 :-)

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 :-)

>>> At what point does prudence become paranoia? 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.
>>>
>> How do you protect the certificate store on the client? Or the binary
>> that ends up prompting for the password on the client
> The certificate 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.

Only as long as you 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)

> 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.

Right.

//Magnus