Issue metadata
Sign in to add a comment
|
Security of personal data on unencrypted
Reported by
tomac...@gmail.com,
May 29 2016
|
||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 Steps to reproduce the problem: Using a settings dump or running computer, extract credit card and saved passwords from the computer Sorry if this is a "feature request" rather than a bug issue, so please redirect to the appropriate location if it is legitimate. What is the expected behavior? Chromium should have an encrypted container for storage of the data that it syncs from the Google account. Chromium should not be content to rely on the hard drive being encrypted and on OS authentication mechanisms not being compromised. For a personal user, the information in Chromium might be the highest priority information on the computer, therefore, security at this level needs to be higher than that of the OS. Users should not be forced into encrypting their OS in order to simply store. Windows 10 does not even offer this in its consumer version. I would recommend setting a security policy control panel, which would enable the user to require a decryption password on browser open and on settings page open, as well as set auto-delete options. The data is backed up on Google's servers, so Google should freely delete this information on password failures and require the user to re-login to Chrome and re-sync bookmarks and other items. What went wrong? Chromium bases its data security measures on that of other browsers and does not think to go "above and beyond" the insecurity of these other browsers with regard to passwords and credit cards. Did this work before? No Chrome version: 50.0.2661.102 Channel: n/a OS Version: OS X 10.11.1 Flash Version: just speculation, and not related to the above issue, but Chromium should consider to build and promote an API for storing password tokens instead of passwords. This way, the tokens can be revoked at the server level instead of requiring a password change on every one of the user's account. It would be very similar to single sign on, except that the tokens would be issued by the merchant site and revoked using their API. In this way, the merchant makes no direct commitment to Google (and therefore does not need implement multiple such mechanisms). If a token is compromised, it should be regenerated by API request. They could periodically be updates (1 week, 1 month, etc) instead of users changing passwords.
,
Jun 1 2016
Thanks. I understand, but I want to clarify that there is a significant difference between the case where a user has privileges to access a running instance of Chrome vs. having access to the raw hard disk contents. In the case of Full-Disk-Encryption, the security model is also compromised at the point where the computer is running and unlocked. Full-Disk-Encryption has many drawbacks, among them resource usages and decreased data recovery, so I don't see it as a given in the personal sphere that data encryption is the way to go. For example, my current Mac Pro at my home could easily have enabled FileVault with one click, but, do I want my high definition videos encrypted also? In this case the risks and disadvantages are not justified. The one exception to this is Google Chrome which stores all my passwords and credit card information. I would add that Windows 10 does not offer FDE as standard but with a $100 upgrade. Take a look at the standard encryption made use of by commercial password managers - far superior to Google Chrome's security https://1password.com/security/. The argument fails in the point where there is a failure to address minor and unsophisticated attacks. When the user hits "view passwords" it is absolutely reasonable to verify their identity. Just because the user "could" hack into the computer memory and get the passwords does not justify giving your password to your unsophisticated friend or co-worker passing by you desktop while your back was turned. Likewise, as explained, the Chrome storage is the highest priority item on a personal user's computer. It not only does not justify their running Full-Disk-Encryption of their family photos, but the average consumer is not as smart as you or I and does not know that FDE even exists and that they are unprotected. To pay $50-$100 for this is also not very reasonable. You write that one can choose what to sync, but this can be changed at any time without a password. You pass the password to websites from autofill, no security requested. Check all payment websites, they ask for re-identification and do not store unencrypted credit card numbers anywhere. I did NOT give Google Chrome my credit card number and I did NOT give them permission to store unencrypted my Google Wallet credit card number. I see the only resolution to this is to close my Google Wallet account. I have submitted just now a request to close my Google Wallet account. I see now that the only reasonable resolution to this problem is to use commercial alternatives.
,
Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 2 2016
|
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by mea...@chromium.org
, May 31 2016Status: WontFix (was: Unconfirmed)