Password encryption

David Balazic David.Balazic at hermes-softlab.com
Mon Mar 17 11:54:55 EDT 2008


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
;-)


> -----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
> 
> 
> 




More information about the Support mailing list