Chris LeBlanc wrote: > After a lot of flying emails, and some thinly veiled wise cracks, it > finally whittled down to this: > > -I wanna build a program that, without any access to Moz code or libs, > can read/write/edit stored username/passwords, so how does Moz store the > data? > > -Moz doesn't really store the data. The file you are looking at is an > ASN.1 DER encoded file just storing pointers to keys.
Close. Moz stores the data, the encrypted password, but not the key used to encrypt it, in the password file. > This morning I sent an email to the list giving a better overall rundown > of the situation, and how Moz does this. The short short version is: > > 1. There is a token, be it software or hardware (such as USB key or > other removable device). > 2. When a Master Password is created, it is associated to/into the token. Right. The master password is the TOKEN's password. How it is used is entirely up to the token. Mozilla has no use for the password other than to give it to the token. In the case of the built-in software token, the token's password is used along with other info and the PKCS#5 algorithm and triple-DES to derive the triple-DES key used to encrypt the database. But that's all subject to change without notice. The part of this that is expected to stay constant is the API that mozilla and/or NSS export to access those keys. The NSS developers are free to change what goes on inside the software token at any time, as long as the external APIs still function. So it's best to plan software that uses the supported APIs, rather than trying to get into database internals. cert8.db is coming, to supersede cert7.db. Programs that fiddle with database internals will have trouble. Programs that use the APIs won't. > 3. When a username/password is entered, it is saved in the token, a > key, algorithm, and pointer information, is stored by Moz in a ASN.1 DER > encoded file, which just says, where is it on the token, and how to get it. Not quite. PKCS11 tokens are able to store keys. Most commonly, they store users' private RSA keys. They don't generally store other data whose format and content is completely unknown to them (although they may store Public Key certificates). So, a key is generated by (and in) the token, and stored in the token. The key doesn't leave the token. The token gives out a number that identifies the key for future use, instead. The key, identified by its number, is used to encrypt the password. The encrypted password is not stored in the token. mozilla takes the encrypted password, the number that identifies the key, the number that identifies the cipher used to encrypt the password, and the initialization vector for that cipher, and encodes them using ASN.1 Distinguished Encoding Rules (DER) into a binary structure. PSM then base64 encodes the result and that's what goes into the password file. > 4. When it is time to get the username password (to use at a site or > delete), Moz calls the token with the algorithm and pointer, and uses > the key to verify the information. Right. Mozilla also passes in the encrypted password. The token uses this info to find the key that it stored, and uses that key to decrypt the password, then it outputs the decrypted password. > The problem comes down to this, someone wanted to know how Moz stored > username/password combos so that someone could access their (hopefully) > username and passwords stored so they could find ones they forgot, edit > ones, remove specific ones, etc. I understand the desire to do this, > because this would allow people to find username/passwords they forgot, > remove old ones, that kind of stuff. Sounds like a great idea for a new contribution to mozilla! > The way it was being described though (using JAVA and HTML) sounded a > little more into the cracker toolkit rather than management. I wondered about that, too. The primary benefit should be the user's security, not ease of third party access to the stored passwords. > I do wonder, has anyone else thought about a system that would allow > people to review their username/passwords. Maybe even have a text file > associated so they could store non-secret info in, such as a comment of > which site that is or how to get there. It would be easy to write such a tool, using the NSS library APIs that mozilla uses to do the very same job. Ultimately, PSM has just two functions, one to encrypt and encode, and one to decrypt and decode. The open source is easy to read. It's here: http://lxr.mozilla.org/security/source/security/manager/ssl/src/nsSDR.cpp#158 > Just wanted to get the ball rolling on this list. > Chris -- Nelson Bolyard Disclaimer: I speak for myself, not for Netscape
