141–150 of 186 posts
Earlier quoted context omitted.
>This is shit developer experience. Why bother with a Rube Goldberg sequence of piped commands when you can just curl? For which developers?
The ones I spoke with when doing user research.
Earlier quoted context omitted.
2-factor authentication does not protect against that. The victim does not know they are being MITMd and enters the 2FA code.
The 2FA device from my bank ( https://nl.wikipedia.org/wiki/Rabo_Scanner ) shows what permission is asked: account login, signing a transaction for amount x, etc.. You might MITM it, but it would be hard to profit, because the only thing feasible seems to deflect some transaction to another account, and it would only work once and raise suspicion quickly thereafter. The bank could encode the permission (amount, benef…
If they tried this at a Canadian bank, every non-technical person would immediately switch to a competitor and they'd lose more money than they'd save via fraud prevention.
> The most realistic threat is the client developer not properly verifying the server certificate, i.e. was it ultimately signed by a trusted certificate authority? From an attackers point of view, this sounds like a very tiny ray of hope. It sounds like a cool feature/vulnerability that will probably be going away soon because it is so easy to fix.
The problem with the, "was it signed by a trusted authority?" concept is that you generally can't automated the 3rd party since they're not under your control. Also, they typically charge every time you request a new certificate (even if client-only). The solution to that is to run your own CA but then it won't be 3rd party anymore. It's sort of the catch-22 with SSL/TLS: Either you use a 3rd party or you get to auto…
Have you seen Let's Encrypt?
Actually oAuth 1.0 is less secure than oAuth 2.0 because it engages in security theater. It doesn't even require https and as a result any man in the middle can eavesdrop on the requests. And if the token is leaked, it's game over.
But you're correct that eavesdropping is possible.
Earlier quoted context omitted.
My DH comment was a bit aside the point I probably should have made. (Also, apologies for my sarcasm re: bash pipes -- that was unnecessary and probably unproductive). > Public key cryptography can be used with JWT tokens but they don't solve the problem of how the client will generate key pairs, demonstrate proof of possession of the private key, and enrol the public key with the API. JWT is not in any way attemptin…
I completely agree with everything you said and know a bit about OIDC too, but since I'm far from mobile/3rd party apps development, there is one thing I don't understand: client credentials (confidential client) in case of mobile app installed from the marketplace. How is it done? You'd need dynamic client registration, right? I know there's a spec for that and I think I understand the mechanics. That would let you…
1) You create a "normal" client in Google Developer console (i.e. a web client) 2) You create a native/Android client in the same project. This client is shared across all phones. 3) You add a scope of audience:server:client_id:$NORMAL_CLIENT_ID to auth requests from the mobile. 4) You get back token minted for the web client, from the native client!
This is how it works:
https://developers.google.com/identity/protocols/CrossClient...
The reason it is safe is because you can only do the cross client stuff from a mobile client, which disallows any redirect urls except for localhost and a couple of other special URIS (see https://developers.google.com/identity/protocols/OAuth2Insta...)
It's ok that the secret is not really secret because it's not possible to use it to making a Phishing site since the redirect URL is localhost.
I guess that doesn't answer your "how does it identity the app developer" but it does tell you how these things are deployed at least, and the important fact that there's just one client (not one for every device)
Let's say your API server followed the standard OAuth 2.0 protocol except required client-side certificates? Would that be as secure as TAuth?
If so, then the OAuth 2.0 option has the advantage of being well-supported by existing libraries and well-understood from a security perspective. It's less likely that a previously-unknown issue with OAuth 2.0 will crop up and force everyone to scramble for a fix.
And while client certificates prevent an attacker from forging client requests (i.e. tricking the API server) an attacker can still trick the client. An attacker capable of MITM'ing server-cert-only HTTPS can also trick TAuth clients into sending it's banking API requests the attacker's servers. It can respond to those requests with whatever it wants.
To summon the activation energy to adopt (or switch to) a new, less-popular protocol, I'd expect more security benefits.