On Wed, Mar 30, 2011 at 01:42:45PM -0600, Michael Torrie wrote: > On 03/30/2011 12:58 PM, Jeff Anderson wrote: > > I agree that for most cases, a public key system is overkill, but I have > > managed to run into an edge case with a password manager where I would have > > been much happier with a public/private key. > > > > One way that I've seen a password manager used was for assigning passwords. > > You'd go to a web application, and enter a new keepassx passphrase. The site > > would then send you a keepassx formatted password store that you could open > > with the passphrase that you entered. The idea was to avoid printing > > passwords > > when distributing new ones. Using a password store seems to be an > > appropriate > > way to get around printing, but sending your passphrase over the network, > > even > > with SSL, is probably a bad idea. With potential XSS vulnerabilities, a > > browser is a very nasty place to put a master passphrase for a new password > > store. > > I'm not sure I follow you. Public key encryption isn't any stronger by > definition than symmetric encryption. So sending it across the wire as > a GPG-encrypted message or through SSL doesn't seem to me to be any > different, security-wise. In fact SSL negotiates a (random) symmetric > encryption key using public key encryption anyway, so can in fact be > more secure than simply using public-key encryption (and much faster > computationally). SSL even changes its key periodically during a > session. And if both sides support it, you can use any algorithm you > want and any key length you want for the actual session. Also you can > even have an SSL connection require a specific certificate on the client > end during negotiation, so the "trust" mechanism can go both ways. > > > Using GPG, you could easily implement a method to assign or share common > > passwords without having to go outside your password manager. The > > application > > or person creating the password simply needs to create it, and encrypt it > > with > > the recipient's public key. No need for the password creator and recipient > > to > > share a common secret. > > I don't understand this either. With SSL there is no shared common > secret either (the secret is random and negotiated on the fly). >
I'm not worried about an SSL man-in-the-middle attack. I'm concerned that the other end is a web application that needs to know the secret (keepassX passphrase) to be used to decrypt files intended for me. How do I know that they won't store that passphrase and use it later to decrypt my passwords? Public key encryption ensures that once the information is encrypted, it can't be decrypted by anyone else, including the party that encrypted it in the first place. All I mean to say is that I'd much rather have my public key floating around in a potentially untrustworthy environment rather than my passphrase for keepassx. I guess one option would be for me to change the passphrase on the keepassx store as soon as I get it. Jeff Anderson
pgptka6tz86iz.pgp
Description: PGP signature
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
