3 ms·

Not going to happen. Most online services require applications that access them to embed hard-coded, obfuscated passwords in the binaries. That doesn't really w

Not going to happen. Most online services require applications that access them to embed hard-coded, obfuscated passwords in the binaries. That doesn't really work for open-source software, and Thunderbird's hard-coded passwords are easily viewed: https://hg.mozilla.org/comm-central/file/tip/mailnews/base/src/OAuth2Providers.jsm#l79 https://hg.mozilla.org/comm-central/file/tip/mailnews/base/s... I don't quite understand how we ended up in this situation. These passwords are more like user-agent strings. But they are still passwords in the sense that without any of them, you can't access (the authentication providers for) those online services.

dns_snek 3y ago
Possession of OAuth Client Secrets doesn't grant you access to any private data, it's a non-issue and it's unrelated to the linked Cisco vulnerability: > A vulnerability in Cisco Emergency Responder could allow an unauthenticated, remote attacker to log in to an affected device using the root account, which has default, static credentials that cannot be changed or deleted.
- fweimer 3y ago
  I understand these cases are structurally different. I just don't see how a quasi-ban of hardcoded passwords could work, given current industry practices. And I'm not sure these client-side secrets/group passwords are entirely meaningless. Some people somewhere must ascribe some security-related property to them.
  - jameshart 3y ago
    I think this is just a case of the APIs here supporting client ids and secrets so that users can control who uses the API on their behalf… but it being up to the API user to decide how much they care about who they share that client secret with. If Thunderbird shared their Netflix password in here, that wouldn’t say anything about the quality of Netflix’s security implementation or the security value of Netflix passwords in general - it tells you Thunderbird don’t care about how their Netflix account gets used. And in terms of the structural difference - this is of course a hardcoded credential used to identify this client to a service - the case at hand is about a hardcoded credential authentication embedded in a service, used to authenticate clients. We can distinguish those cases regulatorily.
mschuster91 3y ago
> I don't quite understand how we ended up in this situation. These passwords are more like user-agent strings. But they are still passwords in the sense that without any of them, you can't access (the authentication providers for) those online services. Blame anti-cybercrime laws and weird interpretations of these for that one. The idea was that, as application level secrets (client_id/client_secret) in OAuth are scoped to a specific legal entity requesting them, site operators like Facebook, Twitter and others could request a takedown of third party apps at app stores for using the secrets of other apps.

dns_snek 3y ago

Possession of OAuth Client Secrets doesn't grant you access to any private data, it's a non-issue and it's unrelated to the linked Cisco vulnerability: > A vulnerability in Cisco Emergency Responder could allow an unauthenticated, remote attacker to log in to an affected device using the root account, which has default, static credentials that cannot be changed or deleted.

fweimer 3y ago
I understand these cases are structurally different. I just don't see how a quasi-ban of hardcoded passwords could work, given current industry practices. And I'm not sure these client-side secrets/group passwords are entirely meaningless. Some people somewhere must ascribe some security-related property to them.
- jameshart 3y ago
  I think this is just a case of the APIs here supporting client ids and secrets so that users can control who uses the API on their behalf… but it being up to the API user to decide how much they care about who they share that client secret with. If Thunderbird shared their Netflix password in here, that wouldn’t say anything about the quality of Netflix’s security implementation or the security value of Netflix passwords in general - it tells you Thunderbird don’t care about how their Netflix account gets used. And in terms of the structural difference - this is of course a hardcoded credential used to identify this client to a service - the case at hand is about a hardcoded credential authentication embedded in a service, used to authenticate clients. We can distinguish those cases regulatorily.

mschuster91 3y ago

> I don't quite understand how we ended up in this situation. These passwords are more like user-agent strings. But they are still passwords in the sense that without any of them, you can't access (the authentication providers for) those online services. Blame anti-cybercrime laws and weird interpretations of these for that one. The idea was that, as application level secrets (client_id/client_secret) in OAuth are scoped to a specific legal entity requesting them, site operators like Facebook, Twitter and others could request a takedown of third party apps at app stores for using the secrets of other apps.