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 <[EMAIL PROTECTED]>
