Re: Spoofing as the postmaster

Magnus Hagander wrote:
> Mark Mielke wrote:
>
>>> 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 :-)
>
Yep.

> 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 :-)
>
Yes. Pseudo-random number generator on an LCD display that changes every
60 seconds, or one of those government satellite-based systems. :-)

Even still, it's often two forms of authentication. With the SecureID
cards, the number proves you have the physical card on your possession,
and the password proves you have access to the person's brain (or piece
of paper that they stupidly wrote their password on :-) ). Most of these
systems are not necessarily effective against kidnapping the person and
threatening to kill them. However, they are very effective against
random hackers on the Internet who are doing trial and error or some
other approach. By denying entry BEFORE the password is provided, they
are unable to guess passwords and get lucky.

>> 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)
>
Correct. I believe this is why I didn't bother. I saw value to using
better than 128-bit AES for the password (as per US export control
regulations), but not for the data (the data was primarily a list of
privileged write requests), and I saw value to making the password
unreadable as soon as possible (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 protecting the client.

>> 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
If it was an easy problem, somebody would have solved it once and for
all, and the CIA would be out of business... :-)

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>