OK, I thought a bit and come up with a much simpler way: - remove passwords from accounts.xml - store them in a file named DO_NOT_OPEN ;-)
(the problem of matching passwords from one file to accounts in another is left as an excercise to the reader) Regards, David > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Luke Schierer > Sent: Monday, March 17, 2008 5:27 PM > To: [email protected] > Subject: Re: Password encryption > > David Balazic wrote: > > Hi! > > > > No, there is a misunderstanding. I talked about 2 (more or > > less separate) things: > > > > - protecting the stored passwords > > > > The simplest way for this is enabling the Encryption in Windows > > on the .purple directory. This is as good as it gets. The only > > more secure way is not to store the passwords on the PC. > > > > If done right, yes, disk (or folder) encryption is secure and > works. I > have not (until now) addressed that portion of your remarks. > > > - preventing passwords appearing text editors > > > > This is the secret key stuff I wrote about. Because the key is > > in a separate file, the data from an editor having the > > accounts.xml open is useless to an attacker (that is attackers > > having a view on the users monitor). > > The purpose of this would be not to protect the stored password data > > from (all) attacks, but to prevent them being showed on the > computers > > display in plain text/sight. Nothing more. > > > > Regards, > > David > > > > PS: I not saying this should be implemented in next or any version > > of pidgin. Just that it would prevent one of the few left over > > attack vectors in case config direcotry encyption is used. > > > > Right, but while this would close off one really rather minor attack > vector, it would increase the user's vulnerability to all other (more > real) attack vectors, because the user would be lulled into a false > feeling of security. > > While some portion of users would avoid that false feeling of > security, > experience working with the pidgin user base leads me to believe that > these users are precisely the ones most likely to know that purple > clients store plain text passwords today, and to have already come up > with what they consider a reasonable compromise between security and > ease of use to cover the situation. > > Thus the security of the user not already handling the > situation has a > net reduction. For that reason, we have rejected obscuring > the password > in favor of waiting and leaving the status quo until something truly > secure against a higher percentage of attacks emerges. > > Again, I'm not arguing that disk encryption is or is not a reasonable > way to handle sensitive data. I'm addressing only the generated key > portion of your remarks. > > The reality is that if we obscured the password as you suggest, the > corporate user who started this thread would think purple > clients secure > for the environment he envisions using pidgin in, when it is > in fact not. > > luke > > _______________________________________________ Support mailing list [email protected] http://pidgin.im/cgi-bin/mailman/listinfo/support
