master password gsoc project

[Vivien Bernet-Rollande]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Laager wrote:
> 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.
I might very well be wrong, but :

BOOL WINAPI Internal Protect Function (
   DATA_BLOB                  *pDataIn,
   LPCWSTR                     szDataDescr,
   DATA_BLOB                  *pOptionalEntropy,
   PVOID                        pvReserved,
   CRYPTPROTECT_PROMPTSTRUCT   *pPromptStruct,
   DWORD                        dwFlags,
   DATA_BLOB                  *pDataOut)

    * /pOptionalEntropy
      /Pointer to a| DATA_BLOB |containing additional entropy used to
      protect the data. The| cbData |member holds the length of the|
      pbData |member's byte string that contains the optional entropy.
      The| DATA_BLOB |used in the protection call must also be used in
      the unprotection call. This is the application specific "secret"
      mentioned earlier.

      *This parameter is optional and can be NULL.*

- From this, it seems the "secret" or optional entropy is pretty much
any kind of data + the size, and it would be possible to use it for a
password. There are some drawbacks to that implementation, but it
seems feasible. This also means we have a total control on the prompt
window's design.
>
> 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.
This would indeed make sense, having a cross-platform plugin. I don't
know if Glib contains any cryptographic code, nor if pidgin is already
linked against cryptographic libs. The patch links against NSS
(http://www.mozilla.org/projects/security/pki/nss/), which is
multi-platform, but adds another dependency. Also, it seems to use
PKCS #11, which is a public-key algorithm, which sounds odd for such a
purpose.
I've seen that there's a whole cipher infrastructure in libpurple, so
such a plugin could probably make use of that code. Haven't checked
what algorithms are available though.
Also, it seems to me it would be a better thing to store the protected
data in another file, unlike the patch, which modifies the structure
of the accounts.xml file.
>
> 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).
The way I see it is the following : by default, the plugin works in a
totally transparent way. The user never gets prompted anything,
password are secured with his system password, simple, clean and easy.
But from the configuration interface, the user could set a master
password, adding an extra layer of security (in case the system
account is shared by multiple users for instance).

I see a few reasons for this. First, one might want to be able to
implement a plugin for a password safe that does not have access to
the system login credentials, and therefore requires the user to enter
a password. Second, some users might like an extra layer of
protection, since having a pidgin-specific password makes it harder
for other applications.

- --Vivien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFINJk130k75O5OLaURAsxkAJ9/4PyMW30MnvMA0TXSw5WsyWPgSgCfUM5e
NryvmGV9g3Sgmj6mpRMvw2c=
=+orF
-----END PGP SIGNATURE-----