Password encryption

[David Balazic]

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: support-bounces at pidgin.im 
> [mailto:support-bounces at pidgin.im] On Behalf Of Luke Schierer
> Sent: Monday, March 17, 2008 5:27 PM
> To: support at pidgin.im
> 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
> 
>