Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

On your last point, Chrome uses the default Windows keyring implementation with no extra password (*pOptionalEntropy [1]), so any Windows application can grab passwords stored in Chrome.

[1] http://msdn.microsoft.com/en-us/library/aa380261%28v=vs.85%2...



What would you suggest Chrome provide as pOptionalEntropy? Please be specific, and note that I don't want to provide a password every time I start Chrome.


Your requirement conflicts with the requirement that passwords stored in Chrome are not discoverable by other programs. Hard-coded optional entropy will just be pulled out of the executable and these programs will still exist; randomly-generated new entropy for each installation of Chrome will have to be stored somewhere if it can't come from the user, and it can be pulled out of there and these programs will still exist. The only advantage that non-user-generated optional entropy will get you is that programs that do not specifically target Chrome passwords, and instead just dump the entire protected storage, will no longer be able to get Chrome passwords.

My personal suggestion would be for an optional user-provided password. I would be surprised if most people who wanted extra Chrome security would mind typing in a password once after starting it.


> do not specifically target Chrome passwords, and instead just dump the entire protected storage, will no longer be able to get Chrome passwords.

That's not how protected storage works on Windows. It's just a simple crypto API. You give Windows some data, it encrypts it with a (user/machine/process) specific key and returns it. It's up to Chrome to store it. So, any bad software would already need to target Chrome's settings files, so hard-coded (or install generated) entropy adds nothing.

There is the Windows Credential storage which is system wide (I think IE uses that), but Chrome does not, to my knowledge. (I've got a hundred entries in Chrome, and only a few certs and passwords in credstore.)

> would mind typing in a password

This is an entirely different suggestion and that sounds like a decent feature but not really. If you want a password manager like PasswordSafe that stores passwords "safely" (and does auto-relock, moves around in RAM to avoid any "ghosting" effects, etc.) then use a dedicated program. Adding it to Chrome adds complexity for little additional security (if your workstation is unlocked, it's almost definitely game over).

And the original article is talking about non-technical friendly culture of leaving stuff around unlocked. Even with a master password, Chrome is left open all the time anyways. So it's a doubly dubious feature. You'd need to add auto-relocking, etc. etc.

If Chrome does all this, one of the Chrome members should implement a lightweight, benign exe that undoes it all in one quick move, shows you passwords, then deletes itself. So you can just hit like new incognito window, https://url.thing/chromepass and immediately undo it all, just to remind people how silly it is.

Edit: Remember that most security threats are remote, and Chrome has been doing a fantastic job on the actual security model. Cert pinning, for instance, prevents vastly more attacks than this complicated password thing would do. Wikipedia says Chrome (and new Safari) are the only current browsers to support TLS > 1.0 (needed to prevent some attacks).

I'm glad the Chrome team is moving with a real threat model, rather than hand-wavy stuff.


Sorry, it appears you are correct about the protected storage. I was basing my understanding on a work discussion we were having, where we appear to have been wrong. Thanks for the correction.


wtf




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: