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