Chrome's insane password security strategy

Re:Chrome's insane password security strategy by SonicHedgehog on Tuesday August 06, 2013 @06:45PM (#6169710)

However, Pidgin “would encourage integration with keyrings” [0]. At least on OS X Chrome uses the integrated keychain and as Elusive mentioned [1] it apparently does encrypt passwords on Windows too.

So, I think Pidgin’s situation is a bit different and if they would have keychain integration they may solve this differently than Chrome does right now.

[0]: https://developer.pidgin.im/wiki/PlainTextPasswords#Isthatth... [1]: https://news.ycombinator.com/item?id=6168039

[ Parent | on HN ]

Re:Chrome's insane password security strategy by interpol_p on Wednesday August 07, 2013 @08:09AM (#6172214)

On OS X Chrome pulls the passwords out of the keychain and then makes them completely accessibly in plaintext through the settings/passwords page. I have no idea why it does this.

[ Parent | on HN ]

Re:Chrome's insane password security strategy by LauRoman on Wednesday August 07, 2013 @10:15AM (#6172958)

How open of a platform is that keychain, and can Apple reserve the right to lock any aplication out?

[ Parent | on HN ]

Re:Chrome's insane password security strategy by interpol_p on Wednesday August 07, 2013 @10:38AM (#6173112)

Keychain is accessible through standard system API calls.

Apple does not require any sort of approval or valid developer certificate to use the Keychain. Any app that attempts to access the Keychain will trigger a system-level notification to the user informing them of what the app wants to access, and allowing the user to "Allow", "Deny" or "Always Allow" the request.

[ Parent | on HN ]