master password gsoc project

[Richard Laager]

On Wed, 2008-05-21 at 13:40 +0200, Vivien Bernet-Rollande wrote:
> It encrypts the data using the user's login credentials, but can use a
> "secret" as a secondary entropy source, for added protection.
> This means it's possible to either have a pidgin-specific master
> password, or just trust that the account credentials are safe.
> more here : http://msdn.microsoft.com/en-us/library/ms995355.aspx

Thanks for that pointer. I was wondering if something related existed on
Windows but wasn't having any luck finding anything. I looked at this
documentation and I'm not sure that this "secret" (which even Microsoft
puts in quotes) would be an appropriate place to stick a user's "master
password". From what I gather, it's a way for an application like Pidgin
to make it more difficult for other applications to grab its passwords.
Given that we're open-source, I'm not sure where we'd store this
"secret". If we generated it per-machine or per-user or whatever, we'd
have to store it (ultimately unprotected). I don't think that's worth
bothering with.

From that page:
'Additionally the application can pass in a data structure that will be
used by DPAPI to prompt the user. This "prompt structure" allows the
user to specify an additional password for this particular data. We
discuss this structure further in the Using DPAPI section.'

Looking at the specifics of the dialog presented, I suppose we'd end up
generating a random secret and protecting that (with the dialog allowing
the user to set a "master password"). Then, on startup we'd unprotect
that (which would yield a "master password" prompt once, if a password
was set) and use it as the "secret" in all of our other
protect/unprotect calls.

This would allow one to have a real Pidgin "master password". However,
if we're going to do that, it would make sense to use that existing
master password patch's approach (i.e. encrypting things ourselves).
That would allow us to avoid using another Windows API and would be
cross-platform. It'd also allow us to control the look of the master
password prompt dialog.

I'm also not sure that a Pidgin "master password" is truly appropriate
anyway. After all, why not just secure things with the login password?
That's what this API seems to do. So apparently, we'd be able to use
this API to encrypt the plaintext password and store it ourselves. (In
contrast, GNOME Keyring will store the encrypted password for us.)

In designing all this, we need to look at the end goals. I think the
goal here is to avoid storing plaintext passwords. In contrast to the
"master password" approach, I (and others) prefer something that is
seamless (and yet secure by being based off a login password).

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20080521/e883bc6a/attachment.sig>