Password encryption

[Luke Schierer]

David Balazic wrote:
> 1.) I did not recommend security by obscurity, just obscurity for it's
> own sake
> 2.) security is provided by encryption (as I posted about 3 times today
> ;-)
> 

You did.  You suggested that libpurple clients generate a key, and store 
that key in a file.  Any attacker could then still simply copy the 
.purple directory to their own space, and either launch 
pidgin/finch/adium to take control of your accounts, or strip the code 
to decrypt accounts.xml from the libpurple source code and use that to 
decrypt accounts.xml using the key they now have.

Security wise, this is precisely similar to simply hashing the password, 
or even just using ROT13 on it, with precisely the same downsides.

Obscurity is a false benefit. We cover this in 
http://d.pidgin.im/wiki/PlainTextPasswords

luke


> 
>> -----Original Message-----
>> From: support-bounces at pidgin.im 
>> [mailto:support-bounces at pidgin.im] On Behalf Of Luke Schierer
>> Sent: Monday, March 17, 2008 4:51 PM
>> To: support at pidgin.im
>> Subject: Re: Password encryption
>>
>> David Balazic wrote:
>>> Yes, but hiding it still has a purpose.
>>>
>>> Imagine this:
>>>  - you open the config file in editor (for whatever purpose)
>>>  - someone walks by and sees your stored password
>>>
>>> A good and simple way to avoid this is:
>>>  - pidgin creates a secret key and stores it by itself into a file
>>>  - all stored passwords are encrypted in the config file(s) 
>> with this
>>> key
>>>
>>> This prevents the above scenario.
>>> And works.
>>>
>>> Regards,
>>> David
>>
>> Okay, so now the password is fully available to the local 
>> admin in the 
>> earlier example, but with one down side: now the user won't 
>> realize that 
>> it is fully accessible to the local admin, but will instead 
>> think he or 
>> she is secure.
>>
>> As I said in the the wiki page explaining our view of this, 
>> in the rare 
>> case that you open your accounts.xml file in a text editor, you can 
>> determine how much of a breach of security has occurred.  You 
>> can weigh 
>> the risk of someone having seen your password (and recognizing what 
>> account it is for, that it is a password, and so on in the 
>> mess of xml 
>> that is in your screen) against the potential benefits of 
>> being able to 
>> recover a password (say you don't remember it and need to 
>> enter it into 
>> the client you chose to use instead of pidgin.  Or say you 
>> need to fill 
>> it into a form on a webpage to change it.  Or a variety of other 
>> possibilities such as adding that account to a new instance 
>> of pidgin on 
>> a different computer).
>>
>> No one in this thread has yet come up with a scenario that materially 
>> differs from any that has come up in previous instances of this 
>> discussion, at least some of which are in the mailing list archives.
>>
>> Unless you can come up with something truly novel that throws 
>> the entire 
>> discussion into an entirely new light, I see no benefit to 
>> obscuring the 
>> passwords that is not outweighed, in the minds of those who 
>> would commit 
>> this code, by the problems that security by obscurity create.
>>
>> luke
>>
>>
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/support/attachments/20080317/c41f16bf/attachment.sig>