3 ms·

> What makes you think you can’t issue per-Client, client secrets at install time? I have in fact used systems like this—this is how OAuth works for Mastodon c

> What makes you think you can’t issue per-Client, client secrets at install time? I have in fact used systems like this—this is how OAuth works for Mastodon client apps. These are in fact pretty secure, and one of the reasons we don't implement PKCE for Mastodon (also because iirc it's annoying to enable in Doorkeeper or there are some gem version conflicts or something). This is required because Mastodon clients have to work with any random Mastodon server, without the client developer being aware of the server or having anything to do with it ahead of time. But again, the way most people think about client secrets is as authentication that a piece of software is what it says it is. This is how e.g. Github, Google, and every other major provider use OAuth. And this concept is what I'm saying is entirely incoherent with public apps like desktop or mobile apps. Registration like you propose opens up completely unauthenticated Sybil attacks on things that almost every other Oauth implementation prefers to keep locked down.

throwaway290 4y ago
Regarding your second paragraph, that was my understanding. But then Github has its own (well Microsoft's) native app that uses OAuth. So I can't see how they ensure an attacker doesn't extract credentials and crypto algorithms from VS Code distribution and get the ability to show any user a genuine "authorize VS Code?" prompt and steal their tokens. But I also doubt they'd just go with a security hole, so either they deal with it somehow or maybe it's not as much of an attack vector as I think...
SgtBastard 4y ago
> Registration like you propose opens up completely unauthenticated Sybil attacks I proposed no such thing. If it’s important to know which client made a particular call, then it’s important to authenticate that client. An old school CD-key can provide a one time shared secret to bootstrap a client install, or even a PBKDF if matched with a serial number to securely share the client secret. Most implementations are concerned with AuthN and AuthZ for users and don’t require these extra controls for client security (i.e. you don’t care which client instance a user interacts with) I was responding to erroneous assertions that these controls couldn’t be implemented.

throwaway290 4y ago

Regarding your second paragraph, that was my understanding. But then Github has its own (well Microsoft's) native app that uses OAuth. So I can't see how they ensure an attacker doesn't extract credentials and crypto algorithms from VS Code distribution and get the ability to show any user a genuine "authorize VS Code?" prompt and steal their tokens. But I also doubt they'd just go with a security hole, so either they deal with it somehow or maybe it's not as much of an attack vector as I think...

SgtBastard 4y ago

> Registration like you propose opens up completely unauthenticated Sybil attacks I proposed no such thing. If it’s important to know which client made a particular call, then it’s important to authenticate that client. An old school CD-key can provide a one time shared secret to bootstrap a client install, or even a PBKDF if matched with a serial number to securely share the client secret. Most implementations are concerned with AuthN and AuthZ for users and don’t require these extra controls for client security (i.e. you don’t care which client instance a user interacts with) I was responding to erroneous assertions that these controls couldn’t be implemented.