Closed Bug 29738 Opened 25 years ago Closed 16 years ago

use better file names (and subdirectory) for the single signon files


(SeaMonkey :: Passwords & Permissions, enhancement)

Not set


(Not tracked)



(Reporter: sspitzer, Unassigned)


the file names for the single signon files are poorly named.

for example, in my ~/.mozilla/sspitzer directory, I have:


egads, can that be made more human readable, so people will know what it is?
The whole idea is that we don't want people to know what it is.  This was 
brought up a security-review meeting.  The action items that came out of that 
meeting was that we use random file names to foil an attack that involves 
searching for files with known names.

Consider an attacker who has figured out a way to fetch files from your machine 
but he doesn't know what files you have.  Such attacks have happened in the 
past.  So a lucrative file for him to try to fetch would be the file containing 
the stored passwords.  If it had a standard name, he would go for it.  But with 
random names, it makes this attack extremely difficult.

Marking this report as invalid.
Closed: 25 years ago
Resolution: --- → INVALID
wait a second, this is security by obscurity, and it isn't even obscure, thus
it's not even secure either.

I look in my prefs.js file (which has a well known name) and I see this:
user_pref("wallet.KeyFileName", "40290823.k");

Gee, I guess I now know what the name of this file is - not so obscure now.

So, if there is some attach that can retrieve specific files from your machine,
it is as simple as this:
- retrieve the well-named file c:\program files\netscape\users50\alecf\prefs.js
- look for the wallet.KeyFileName preference
- retrieve the <walletfilename> using the same attack

adding jar because I think he may have some comments on this

I think it is wrong to litter people's hard disk with these files, and I more
than likely, we'll get slammed by someone in the press because "Netscape stores
your private information in unusually-named files on your hard disk. The file
names seem random so this reporter couldn't even guess at what they could be
used for."
also, since there will be a bunch of these files, they should be under

~/.mozilla/<profile name>/wallet/*


~/.mozilla/<profile name>/signon/*

or whatever.

re-opening, and changing summary.

at the least, we could move them down a directory, so people will know what they
Resolution: INVALID → ---
Summary: user better file names for the single signon files → user better file names (and subdirectory) for the single signon files
and, if a cracker can get your files, they could grab all files under ~/.mozilla
anyways, right?  the cracker could get them no matter what they are named.

The goal is to avoid having another "honey pot" to attract folks.
The prefs file is already a "known honey pot," and we go to a fairly large 
effort to protect that file from being read.  There is no reason to add more 
files to the list.
The "obscurity" amounts to a "password" (the name of the file).  Yes, it is true 
that file name could be read IF you can read the directory listing... but there 
again we try to preclude such activities. 
In the lingo of security: We live via belt AND suspenders.  Having the 
(relatively) secret (and randomly generated) name is a second line of defense.  
I hope that helps explain where we are, and why.
Jim - I completely understand what you're saying, but I think there's something
you're missing: this file is not actually protected at all because the name of
the file _is_ _stored_ _in_ _prefs.js_, which _is_ a well known (named) file.
This means that you don't HAVE to be able to read the directory in order to read
the file - you just need to be able to read prefs.js!

I wouldn't feel so strongly about this if it were just a garbled filename - but
this is a garbled filename that is completely unprotected and completely
discoverable, thus automatically making it a "honey pot" :)
Wow, this sure is invoking a lot of interest.

I guess I was wrong to close this out as invalid -- there certainly are points 
to be made about this issue.  But based on jar's comments in this report and 
norris' and kevin's similar comments at the security review meeting, I have to 
agree that the random names do add an additional barrier against a potential 
attack.  Granted if the attacker could get prefs.js, the game is lost.  But 
that's no reason to make it easier for him.

So I'd like to reclose this as wont-fix unless there are still some strong 
It seems like there are two distinct issues here.  One is seth's concern that 
the user has no idea what these cryptically-named files are for.  I didn't 
know that this was ever a concern.  Certainly the typical user is not going to 
be looking at the names of files in their profile directory.

The other issue is alecf's concern about the names being discoverable in 
prefs.js.  Here's a proposal for that issue:

Instead of using randomly-generated names, have the name be generated by a hash 
of the user's master password.  Its still a cryptic name so seth's original 
concern isn't being addressed.  But we wouldn't have to reveal them in prefs.js 
but rather the browser can calculate it at the time that it needs to fetch the 

I don't know if this is really worth doing, but I'm offering it as a suggestion 
in case others feel that the storing of the names in prefs.js is a security 
how about moving them into a subfolder, under the profile directory.

so on unix, ~/.mozilla/sspitzer/wallet/*.[k|u|p]

at least that, the user has an idea what the files are for.

in 4.x, we do that with the cache files, ~/.netscape/cache/*
I like the idea of making the filenames a (cryptographically secure) hash of the
user's password. How hard is that?
Probably not that difficult.  The bigger problem will be one of migration since 
now we'll have some users that already have the old types of files.
I'm now thinking that hashing the password to create the filename may not be a
good thing. If an attacker has a way to get a directory listing (past JavaScript
exploits have permitted this) he would then have the information needed to mount
a dictionary attack against the user's password. Is there some seed value for
the hashing function that could be used?
If you wanted to use a hash, you would actually have a "seed" that would be 
stored in the prefs.js file, and then the hash would be a combination of the 
seed and the password (classical prevention of the dictionary attack you 
mentioned).  The only hassle (which actually almost exists today) is that you 
have to watch for name collisions with the existing file names.  If you wanted 
to go wild, you could even put the files several level deep in 
dir1/dir2/dir2/file where each dir name was part of the hash. ...but then you 
can get burned with directory length beyond the allowed depth... so there are 
costs for each of these attempts to increase the extent of the hiding.

To be honest, this stuff might make this element more secure, but I suspect we 
have bigger fish to fry.  For example, the security of the contents will 
primarilly be based on the encryption of the contents as needed.  I'd rather 
focus on doing that well, than spend a lot of time making the file name 
convention more complex.  It seems like we have more than enough strength in the 
current file name.  Any attack that can get the directory listing can get the 
file name no matter how we cook it.  

There is some increase in security by removing the name from the prefs.js honey 
pot... but I think we have a lot of info that we'll be sad to loose there... and  
the encryption of our oddly named files should be rather substantial.   We would 
have some site name exposure (plain text in the funny files)... but that is akin 
to being able to read the history file.  There would be some user name 
exposure... but here, if there was a technique for reading an arbitrary file on 
the user's disk, I'd expect that there would be much more interesting files to 
Target Milestone: M20
Closed: 25 years ago25 years ago
Resolution: --- → LATER
Reopened per management's every changing mind.
Resolution: LATER → ---
Severity: normal → enhancement
Target Milestone: M20 → M30
Changing fictional "M30" to reality
Target Milestone: M30 → Future
spam: mass-moving open password manager (single signon) and form manager
(autofill) bugs to Terri for qa contact. unfortunately, i cannot cc myself with
this form, so feel free and add me if you want to keep me in the loop with any
(but, pls not all :) of these... will also go thru 'em meself, a bit later...
QA Contact: sairuh → tpreston
fix typo in the summary.
Summary: user better file names (and subdirectory) for the single signon files → use better file names (and subdirectory) for the single signon files
Summary: use better file names (and subdirectory) for the single signon files → [z]use better file names (and subdirectory) for the single signon files
Summary: [z]use better file names (and subdirectory) for the single signon files → use better file names (and subdirectory) for the single signon files
Whiteboard: [z]
Keywords: nsbeta1-
Netscape nav triage team: based on Steve Morse's pretriage recommendation, this 
is not a beta stopper.
Assignee: morse → nobody
Whiteboard: [z]
now there's no need for weird looking filenames since the profile directory 
ifself is located under the .slt directory.
OS: Linux → All
Hardware: PC → All
When it comes to security, the more the better.  Otherwise it's not necessary 
for you to have an ignition lock on your car because the ignition lock itself is 
inside the car protected by your door locks.
read what alec said:
the filenames are stored in the prefs.js file....!
user_pref("signon.SignonFileName", "1949686.s");
user_pref("wallet.SchemaValueFileName", "2033750.w");

so there's no need in making weird looking filenames that nobody understands
since everybody, if they have access to the profile directory, can find out the
This whole thing is completely stupid. If someone has access to your profile
directory, it doesn't matter at all how you name the file. No matter if you give
it a ranom name or if the name is a number calculdated from the master password
(BTW, what is the user has not enetered a master password)? An attacker will
simply copy the whold directory, all files, no matter how they are named. Then
he has hours of time to find the password file and if he has to look at every
single file and he will find it.

If you give the password file a well-known name, Linux users can at least remove
the read access for group and others, which is often enabled by default. But if
they can't even find it...

Security by hiding the sensible data is no security at all and has never worked.
I would like to store my wallet files in an usb key for sharing between home and
several computers at office. I can't share the whole mozilla profile since I use
Windows and linux mixed environments. 
Why wallet.SchemaValueFileName and not wallet.SchemaValueFilePath in user prefs ?
I've got the same problem as Comment #25

I'm looking to consolidate all my passwords and PKI keypairs onto a virtual
volume on an encrypted USB jumpdrive and I can't configure my prefs.js on my
various machines to all look for the signon file on my jumpdrive.
Product: Browser → Seamonkey
This also makes it impossible to move my passwords from, say, firefox to seamonkey.
hi all! why not make an extension that could export and import the passwords list to any mozilla/firefox/seamonkey browser? i know i need one, since i need to export my passwords list to a readable file for cross-referencing...
QA Contact: tpreston
Priority: P3 → --
Target Milestone: Future → ---
Fixed by Bug 390025 (Move to LoginManager and remove wallet from SeaMonkey)
Now using "signons.sqlite" as the filename.
Closed: 25 years ago16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.