master password gsoc project
elb at pidgin.im
Wed May 21 09:36:45 EDT 2008
Vivien Bernet-Rollande spake unto us the following wisdom:
> William Ehlhardt wrote:
> > It seems to me that a built-in-to-Pidgin master password encryption
> > mechanism would be useful. It can certainly be overridden if an
> > external password safe is present, and would also be useful on
> > platforms where there is no such safe (Does Windows have a password
> > safe that you can integrate with?). If the cited patch provides a
> > libpurple-specific keystore already, most of the difficult work here
> > has already been done.
> There's a page on why the passwords are kept unencrypted here :
> The basic idea is that just obscuring passwords gives a false sense of
A master password system is not insecure, and is not treated as such
on that page. This is the "Store a password behind a password" case.
We are not a big fan of the approach of having a master password per
program, but security-wise it is not a terrible approach.
> Now, regarding a builtin master-password encryption mechanism, it is
> indeed an option. The thing is, once the rest is done, doing this would
> be a simple matter of writting a few cryptographic routines in a plugin.
This is the biggest difference between the master password patch and
the SoC approach. The Summer of Code project will create a framework
into which password storage systems can be plugged, one of which could
be a simple encrypted and password-protected file in ~/.purple. The
master password patch applied in this instance is a specific
implementation of the latter, without provisions for other storage
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel