1259652 - Security issue : You should Provide password to open the cookies.sqlite file.

Status: RESOLVED DUPLICATE of bug 56788

(Core :: Networking: Cookies, enhancement, P5)

Description

[MuthuKumar]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

It is a bounty issue . You should Provide password to open the cookies.sqlite file. Because if a hacker hack this file of a victim, hacker can login into any websites that logged in by a victim at this time on firefox. 
I successfully hacked  cookies.sqlite of my friends with a malicious code created by me.
All are know that ,the cookies.sqlite file is in [{homeDirectory} /Library/Application Support/Firefox/Profiles/{randomfilename}.default/]  the folder in mac .     
I put  malicious code in calculator jar application and send  this jar app to my friends .When my friends run that jar a calculator screen will appear and in background malicious code read the cookies.sqlite file and send this file to my website ..In this way i take cookies.sqlite file without knowledge of victim..my website download this cookies.sqlite file .. And i use this file i hack my friends gmail account..



Actual results:

It is neccessary to provide password to cookies file


Expected results:

It is neccessary to provide password to cookies file

Comment 1

[Daniel Veditz [:dveditz]]

Our current threat model does not include local attack code with access to the user's files. If there were a password on the cookies file the user would have to enter it at some point when running Firefox to unlock it, and our experience with the "Master Password" feature is that most people don't like that interruption. If we did implement something like this we would of course tie all these together (hopefully under better user experience) so it wasn't a bunch of separate passwords.

This is more or less a duplicate of requests to require a "log-in" for Firefox profiles. Some people requesting that don't care if the files are encrypted--they only want enough to discourage curious snoopers with no real technical knowledge--so I'll leave this as a separate request.

This does not warrant a bug bounty because this is a known limitation.

Comment 2

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 3

[Andrea Marchesini [:baku]]

Daniel, should we mark this bug as WONTFIX?

Comment 4

[Daniel Veditz [:dveditz]]

I could be sold either way. I don't know what kind of password we could use that would be known to Firefox but not known to a malicious program running under the user's account as described. Not everyone has a master password or sync password. If we build it into Firefox then everyone could get the One True Password by looking in the source code or binary. If we use the OS store then every program running by that authorized user will be able to get it. At least other users of a shared computer couldn't, but proper directory permissions on the profile file ensures that as well.

So, yeah, it's unlikely we'll be able to do anything about this.

Comment 6

[Enzo]

Any news of this issue ?

I get it that cookies are not in your threat model, but them why encrypt the passwords with the Primary Password them ? It only creates a false feeling of security with the user thinking that all of their credentials are protected when they enable it.

As I said in #1743810:
Storing unencrypted cookies can be dangerous as much as storing unencrypted passwords, it doesn't matter if the cookies are supposed to be used like that or not, the fact is that a huge amount of websites won't check anything beyond the cookies to do the authentication. Chromium already does it since a long time.
Firefox could use the primary password that already encrypts the stored passwords and extend it to encrypt the cookie database too.