Password Management and access
Chris LeBlanc
We at MozSec (Mozilla Security) have been having a wonderful little
discussion with someone who goes by the handle of TGOS.
He was wondering about the way Moz encrypts username/passwords that have
been saved. He was under the impression that Moz saved this to a file
and just encrypted that file using the Master Password as the key.
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.
-That sucks, where are the actual username/passwords stored.
-Somewhere else.
-What! This is just security through obscurity and that never works.
This Sucks (again).
Sorry, couldn't help but vent.
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.
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.
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.
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. The way it was being described
though (using JAVA and HTML) sounded a little more into the cracker
toolkit rather than management.
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.
Just wanted to get the ball rolling on this list.
Chris
Nelson B. Bolyard
> 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