Closed Bug 29738 Opened 20 years ago Closed 11 years ago
use better file names (and subdirectory) for the single signon files
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?
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.
Status: NEW → RESOLVED
Closed: 20 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 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."
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.
Status: RESOLVED → REOPENED
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. Thanks, Jim
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 objections.
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.
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → LATER
Reopened per management's every changing mind.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
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
Netscape nav triage team: based on Steve Morse's pretriage recommendation, this is not a beta stopper.
Assignee: morse → nobody
Status: ASSIGNED → NEW
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 filenames....
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.
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...
Priority: P3 → --
Target Milestone: Future → ---
Fixed by Bug 390025 (Move to LoginManager and remove wallet from SeaMonkey) Now using "signons.sqlite" as the filename.
Status: NEW → RESOLVED
Closed: 20 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.