A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am wondering what is the pro/cons of using public/private key pairs vs password for an automated system to login a remote web server. Maintaining and securing all the private keys can be management issue. But just for the sake network transmission security, which one is safer? Can anyone help on this?
Friday, June 22, 2007
A password is subject to a man-in-the-middle attack. Public/Private keypairs arn't. If you don't control the entire network you're on, you don't want to use a password.
That being said, stuff like ssl and ssh uses public/private keys to secure the data before you type a password, so you're at least not sending clear text. In that case though it's still a little easier to guess a valid password than a valid key.
If you have control over both systems and want best class security you want dual certs with the server set to require client certificate and the specific name for the machine whose cert it will accept, or more loosely, at least a domain it will accept.
That covers security for ensuring only the correct machines are talking to each other. However if you don't trust your client machine or the environment it's in, you may also be interested in using some sort of password to make sure the right *application* is doing the conversing.
Don't send a plain password, even over SSL, use a salted hash so that compromising your client is less likely to compromise your security settings.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz