Arrakis wrote: > I am trying to generate pre-configured credentials for Thunderbird, that > have been Master Password encoded.
The Master Password doesn't work as you probably think it does. You may or may not be able to do what you're attempting. > Firstly, I notice there is no prefs.js configuration that tells the > program that the Master Password has been set. In some versions of some mozilla products, it is in the pref wallet.crypto. But the authoritative source of that information is in key3.db, whose format is private to NSS (the crypto libraries in mozilla products), and changes from time to time. The contents of key3.db are encrypted with various keys. The API for access to it is stable, but the private file contents are not. The crypto DB are going to change again in FF3. so use the APIs. > Should I assume that Thunderbird/Firefox can figure this out simply by > looking at the signons.txt or some other file? Yes, By calling the appropriate NSS or PSM API. > Next, it appears that username/password is stored as base64. Encrypted, then combined with other info, and then base64 encoded. > Inside that base64, how is it encrypted? It is encrypted using an API designed for this purpose, known as the "Secret Decoder Ring" (SDR) API. It is encrypted using a key that is NOT derived from the Master Secret. Secret Decoder Ring is a cutesy name that doesn't sound like strong crypto, but don't let the name deceive you. > I see reference to pkcs11, so > should I assume there are java keystores involved? No, pkcs11 is not a Java interface, so why would you assume it is Java? > More to the point, are there any scripts/utilities that would allow me > to take a plaintext master password (or hash thereof if that is what you > use), generate the key3.db, and use that to encode the plaintext > password/usernames and then base64 it so I can mock the current setup > for thunderbird? No. The key used to encrypt the usernames and site passwords is NOT derived from the Master Password. Two users may have the exact same Master Password and yet still will not be able to decrypt each other's site user names and passwords. The Master Password is the login password for one of the built-in PKCS#11 software "tokens" (a.k.a. "devices"), which lives in a PKCS#11 "slot", accessed through a PKCS#11 "module", which is a shared library. Inside that token is a randomly generated key, the SDR key, which is not derived from the master secret. Each user's "profile" has its own separately generated SDR key. Except by extreme coincidence, no two users generally have the same SDR key, even if they have the same Master Password. Logging into the token with that token's login password (the "master password") unlocks that token's SDR key. The SDR key is used to encrypt and decrypt the contents of the file of the user's saved passwords. The name of that file varies from product to product and from release to release. In some releases of some products, it is known as "signons.txt". The c SDR API is declared at http://lxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11sdr.h#43 and implemented at http://lxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11sdr.c#252 You will find the mozilla client code that uses the SDR API at this URL http://lxr.mozilla.org/seamonkey/source/extensions/wallet/src/wallet.cpp#652 and more at http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsSDR.cpp#243 You will find the source code for a c program that uses the SDR API to decrypt the contents of an encrypted password file at this URL: http://lxr.mozilla.org/security/source/security/nss/cmd/pwdecrypt/pwdecrypt.c > What will I need? I have all the inputs, I doubt it. You will need the user's key3.db, because it alone contains the user's SDR key (encrypted with yet another key). Having the user's plain text master password without also having the user's key3.db will not help you with the user's encrypted password file. > I want to generate the outputs and plug them into > the profile directory. If the user's profile is brand new and starting from scratch, you could create a new set of crypto DBs, including a key3.db, with a newly created SDR key for each one, and deliver the package including the key3.db, and the signons.txt file (or whatever it's called in the product you're using). But if the user wants to preserve his existing saved passwords, that won't fly, and you'll need the user's key3.db to do what you want. Of course, we would not recommend that any user accept a key3.db from someone else, nor give his key3.db to someone else. Note also that the SDR APIs are not scriptable. You can't just download JavaScript that will do all this in the user's browser. If JavaScripts could get access to the key DB contents, users would have no crypto security. > Thanks in advance, > Steve I imagine you will find all this somewhat discouraging. Let me suggest that you take another approach, one that does not depend on shared secrets (passwords). -- Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
