Hello. Thanks for your report.

Assuming that we have passed pOptionalEntropy during encryption, we need it for decryption then. The question: where and how would you suggest to store that value of pOptionalEntropy to keep it safe from an attacker having an access to victim's files?

If you suggest to have a MasterPassword (I guess that user will have to enter that MasterPassword every time while saving a new password or using already saved one, like it works in password managers), how would you protect that password from an attacker?

Also please take look at Chromium security model, especially on physically-local attacks:
https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-

Thanks for replying and sorry for the late reply.

I agree with you.
Masterpassword saved a localfile is needed encrypting and it is also problem.
However, It is problem not to neglect. It will have no meaning even if we prevent physical access.
Data on the server is decrypted, I suspect it is the same thing to decrypt data on the server.
I think that chrome should show a dialog every time if necessary.

There is two suggestion.
First. Could you save masterpasword on your server? I think passwords associated with account is guaranteed. In the first place, I doubt about saving passwords saved on the server to localstorage.
In modern times, computers are almost always connected to the network. I suspect the browser is developed based on it. There is also a function called CryptProtectMemory so please consider it.
However, we cannot perfectly protect local only passwords.

Second. Storing it on the server is the same with first. Allocate ID to a browser, save entropy based on ID, it is saved on server. When a browser create entropy, a browser shows dialog for creating entropy to users, then a browser can decrypt on offline.

Existing browsers have almost the password management function, and they have similar problems. However, the problem is left behind as it is if neglect. Would you mind moving forward? I hope because I like Chrome.
The user is amazingly a beginner. Please protect our passwords.
I hope it will be helpful to you.

An attacker need not go through the trouble of calling the API directly; given physically-local access to your system (or malware running at user privilege), he can simply navigate Chrome to a page that uses the password, right-click the password field, choose "Inspect Element" and grab the text using the Developer Tools. Or he can open chrome://settings/passwords and click "Show" beside each.

A "Master password" already protects all of your Chrome passwords on Windows. That password is your Windows user account password, which also protects the key used by CryptProtectData. 

Thanks for replying.

I know it.
I'm talking about can be decrypted just calling the API from an external application.
I suspect Chrome's dialog for decrypting has no meaning at all for an external application.

> can be decrypted just calling the API from an external application.

Right, and the point is that a malicious application doesn't even need to call the API, they could simply grab the data out of the Chrome process itself. Further, that would continue to be true even if Chrome started salting the data using the Entropy field in the API.

As Microsoft says in https://technet.microsoft.com/en-us/library/hh278941.aspx:

Law #1: If a bad guy can persuade you to run his program on your computer, it's not solely your computer anymore.
Law #2: If a bad guy can alter the operating system on your computer, it's not your computer anymore.
Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore.

These facts are why local attacks are outside the scope of browser threat models.

I agree with the points in comments 3 and 5. There's not much we can do here.

Hmm... I didnt know about its page.
If you care about this, it is certain that you will not settle for eternity. There must be a compromise somewhere.
I reported because I was warried about this. I learned a lot, thank you.

Issue 700738 has been merged into this issue.

 Issue 732723  has been merged into this issue.

 Issue 784076  has been merged into this issue.

 Issue 801876  has been merged into this issue.

 Issue 807226  has been merged into this issue.