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

Status: RESOLVED FIXED

(SeaMonkey :: Passwords & Permissions, enhancement)

Description

[(not reading, please use [e-mail] instead)]

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

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

51853843.p
51853843.u
51858695.k

egads, can that be made more human readable, so people will know what it is?

Comment 1

[Stephen P. Morse]

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.

Comment 2

[Alec Flett]

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
nonsecurity-through-nonobscurity.

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."

Comment 3

[(not reading, please use [e-mail] instead)]

also, since there will be a bunch of these files, they should be under

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

or 

~/.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
are.

Comment 4

[(not reading, please use [e-mail] instead)]

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.

Comment 5

[Jim Roskind]

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.
Thanks,
Jim

Comment 6

[Alec Flett]

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" :)

Comment 7

[Stephen P. Morse]

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 
objections.

Comment 8

[Stephen P. Morse]

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 
files.

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 
hole.

Comment 9

[(not reading, please use [e-mail] instead)]

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/*

Comment 10

[Norris Boyd]

I like the idea of making the filenames a (cryptographically secure) hash of the
user's password. How hard is that?

Comment 11

[Stephen P. Morse]

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.

Comment 12

[Norris Boyd]

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?

Comment 13

[Jim Roskind]

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 
read.

Comment 14

[Stephen P. Morse]

.

Comment 15

[Stephen P. Morse]

Reopened per management's every changing mind.

Comment 16

[Daniel Veditz [:dveditz]]

Changing fictional "M30" to reality

Comment 17

[sairuh (rarely reading bugmail)]

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...

Comment 18

[(not reading, please use [e-mail] instead)]

fix typo in the summary.

Comment 19

[Marcia Knous [:marcia]]

Netscape nav triage team: based on Steve Morse's pretriage recommendation, this 
is not a beta stopper.

Comment 20

[Stephen P. Morse]

.

Comment 21

[Henrik Gemal]

now there's no need for weird looking filenames since the profile directory 
ifself is located under the .slt directory.

Comment 22

[Stephen P. Morse]

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.

Comment 23

[Henrik Gemal]

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
filenames....

Comment 24

[TGOS]

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.

Comment 25

[JC Godien]

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 ?

Comment 26

[Gene Wood]

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.

Comment 27

[James Rome]

This also makes it impossible to move my passwords from, say, firefox to seamonkey.

Comment 28

[Noel Cruz]

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...

Comment 29

[Philip Chee]

Fixed by Bug 390025 (Move to LoginManager and remove wallet from SeaMonkey)
Now using "signons.sqlite" as the filename.