15 ms·

Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

311 points by AffableSpatula 10y ago

bgidley 10y ago
This is unlikely to work - developers in general can't cope with managing SSL certificates. They won't know what to do with them or handle them securely. You need full integrity verification, with a secure store and whitebox crypto keys to make such a scheme secure.
- gyre007 10y ago
  I gathered the target group are developers. Devs should be capable of dealing with this if they want higher security.
  - bgidley 10y ago
    Even dev's can't cope. Most apps leak credentials severely. You need integratity verification, obfuscation and whitebox crypto to do this sort of thing securely. All of that is available in the banking world and is often deployed by people like Irdeto (who I work for) and Arxan etc.
    - gyre007 10y ago
      Is that why irdeto.com does not use SSL on their site? Because you're not willing to manage SSL certificates?
      - jessaustin 10y ago
        Wow it doesn't even redirect 443 it just hangs...
  - komali2 10y ago
    This illustrates a question for my I've been wondering for a while - while each developer on a project should have a good idea of security best practice, is it worth it for each to be an expert in security? I've always felt that there should be a member (or team, depending on project scale) for each project who is a "security expert" and can guide decisions for security best practice. So the developers can be aware that they need to tie in an API key at some point, and the security expert can guide the best way to implement that.
- sjtgraham 10y ago
  If you can cope with OAuth you can definitely manage TAuth. The cert and private key are just opaque things you pass to any HTTP client.
  - bgidley 10y ago
    I agree - but as you say OAuth also suffers from MITM weaknesses. I'm just not convinced 'plain' client certs solve that as it's very hard to distribute those securely and manage them. I guess it depends where you see these being used, if used Server to Server it's not too bad, but if pushed out mobile devices (as I suspect they will be) they are very likely to leak unless strong app protection is applied. If you're banking on strong app protection working you really need to be notified of it's state on the server which this won't do, you need to use a securely signed message from the verification/protection libraries on the client. That can be done by storing this key into a cryptographic whitebox and then linking using it to integrity verification.
    - sjtgraham 10y ago
      This is the first version of TAuth where only server apps are in scope. Work is already underway on the solution for Mobile… Teller will need it soon for upcoming products.
- atonse 10y ago
  > developers in general can't cope with managing SSL certificates I'd say the same but they've done just fine publishing anything to the App Store, which uses certs everywhere. And it was even worse the first few years.
  - duaneb 10y ago
    > I'd say the same but they've done just fine publishing anything to the App Store, which uses certs everywhere. "Just fine" is a relative term here. It's still a shit show managing them—AFAIK XCode is the only realistic option, which makes me want to remove my eyes with forks.
- ForHackernews 10y ago
  > developers in general can't cope with managing SSL certificates https://news.ycombinator.com/item?id=11637700 https://news.ycombinator.com/item?id=11637700
gyre007 10y ago
It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure. I wonder if this is a custom built solution or if Teller.io is using something like HashiCorps Vault to do the whole SSL cert dance. Either way, this looks promising.
- mgkimsal 10y ago
  > It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure. Not when you consider we've all been subjected to decades of "don't write your own security!!!"
  - sjtgraham 10y ago
    Author here. This is not a new invention. This is standard TLS, and some newer things like WebCrypto brought together.
0x0 10y ago
I thought client certificates were being phased out, didn't Chrome just remove the <keygen> html tag?
- sjtgraham 10y ago
  A PKCS#10 request is built using PKI.js, all crypto is done by native WebCrypto APIs.
- kaeso 10y ago
  Kind of. Starting from 49, the <keygen> feature needs to be whitelisted per web-site. Client certificates are not anymore imported automatically, only downloaded (user action needed to load into the keystore).
- supergeek133 10y ago
  You're going to see a lot more of this, especially in the IoT world. PKI is becoming a requirement.
- j_s 10y ago
  Recently I've heard rumblings that HTTP/2 somehow doesn't support client certificates. Can anyone point me to more information on this issue? https://news.ycombinator.com/item?id=11556762 https://news.ycombinator.com/item?id=11556762
jhuckestein 10y ago
As much as I love Stevie, teller.io and this demo: Why not both? OAuth 2 is not "bad" in general, you just need to consider the implications of using it. If you have an API that allows clients to move customers' money or take out loans, you should take additional steps to defend against MITM attacks. For example using client side certificates :) That said, TAuth looks really good and tidy. Of course the developer may still lose the private key, so in the end you'll always need to additionally monitor API requests for suspicious behaviour.
- sjtgraham 10y ago
  Hey Jonas! TAuth is simpler than OAuth 2.0 and doesn't suffer the same security issues. So… why use OAuth?
  - jhuckestein 10y ago
    The devil you know I suppose ;) IIRC we didn't go too far down the client cert route because we're behind CloudFlare and we like it that way. Something to revisit in the future.
  - lmm 10y ago
    The three-legged flow from OAuth is widely needed. (I would agree with sticking to earlier versions that allow more specific tokens though)
- deleted 10y ago
  [deleted]
poorman 10y ago
Must be British... "authorisation" ?
- takno 10y ago
  It uses a UK phone number and supports an EU banking initiative, so I would guess so. Why is that relevant?
  - camhart 10y ago
    authorisation is spelled authorization, atleast in the US
    - maknz 10y ago
      It's spelled authorisation everywhere else.
chatmasta 10y ago
One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log into BankOfMars 5) MyLittleApp has full control over the DOM presented to the user since the WebView is technically its own. 6) MyLittleApp extracts the user's password from the DOM of the WebView 7) MyLittleApp disappears and... profit?
- Freak_NL 10y ago
  Wouldn't this be a reason to promote the use of (trusted) web browsers and web applications instead of native apps or third party API's for high security scenarios? While TLS verification is something that is not flawless, it is something that users are being constantly reminded of by their banks and governments (check the domain name, check the green lock next to it), and modern web browsers go to great lengths to improve the user experience for keeping an eye on the validity of a website. When I pay for something at a webshop via my bank account using a common standard created for that purpose (IDEAL in the Netherlands, other countries have similar systems) I get forwarded to my bank's authentication service to authorize that payment. I can clearly see that the TLS certificate belongs to my bank, and my browser is content that it is valid.
- _lex 10y ago
  OAuth is, like much of authentication and authorization that has been well marketed, very technically flawed. It makes a big show of not trusting the recipient application with credentials, but anyone who's actually interested in stealing creds still can. Plus it's way more complicated and has way more failure scenarios than simple password auth. The only saving grace that I saw was that a service no longer has to store users' passwords to other systems, for persistent interaction with their data. I think this is really why people bother using it.
  - supergeek133 10y ago
robinduckett 10y ago
https://xkcd.com/927/ https://xkcd.com/927/
- emodendroket 10y ago
  Can someone just blacklist every post that is nothing but a link to this comic.
  - robinduckett 10y ago
    Can someone just blacklist every post that is nothing but a new standard trying to add to the list of crappy pre-existing standards? Also, you forgot the question mark on the end of your sentence there. Unless you meant a sarcasm mark or an interrobang and the comment parser stripped it?
amluto 10y ago
Some features that I think a system like this should have: 1. The client (or the device holding the authentication token, or the app, etc) should be able to maintain (on its own storage!) an audit log of all transactions it has authorized, that log should be cryptographically verifiable to be append-only (think blockchain but without all the Bitcoin connotations), and the server should store audit log hashes and verify that they were only ever appended to. And the server should send a non-repudiable confirmation of this back to the client. Why? If someone compromises the bank or the bank-issued credentials (it seems quite likely that, in at least one implementation, the bank will know the client private keys), the client should be able to give strong evidence that they did not initiate a given transaction by showing (a) their audit log that does not contain that transaction and (b) the server's signature on that audit log. 2. Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves. Did I read it wrong? 3. An obvious place where an HSM fits in. How does TAuth stack up here? Also, there's a very strange statement on the website: > to unimpeachably attribute a request to a given developer. In cryptography this is known as non-repudiation. Is that actually correct as written or did you mean "to a given user"?
- sjtgraham 10y ago
  > the bank will know the client private keys No one knows the private key other than the creator, in this case the developer. > Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves. There is nothing stopping the API provider enforcing layer 7 signatures too, it's an application concern. The same private key can be used to compute those signatures or as X.509 certs can embed arbitrary public keys, you can choose another one for transaction signatures. > Is that actually correct as written or did you mean "to a given user"? The first version of TAuth is for Server to server apps. In this case it means developer. I will clarify that in the post. Thanks.
  - amluto 10y ago
0xdeadbeefbabe 10y ago
> 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.
- riskable 10y ago
  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 automate things. There doesn't appear to be any middle ground. Why is there no middle ground? Because if the 3rd party CA is doing their job they're investigating every single request for a new certificate. That means you can't just get a new client-side certificate on demand, instantaneously whenever the need arises.
  - 0xdeadbeefbabe 10y ago
    "client developer not properly verifying the server certificate" makes it sound possible, but I think I understand the problem now maybe. The 3rd party CA may have issued a cert to malicious party that issued another cert to their man in the middle. You can't be sure unless you are your own CA, but then you aren't a 3rd party anymore.
  - aianus 10y ago
    > Either you use a 3rd party or you get to automate things. There doesn't appear to be any middle ground. Have you seen Let's Encrypt? https://letsencrypt.org/ https://letsencrypt.org/
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
zaroth 10y ago
The premise for adding client certificates is a MITM made possible because careless app developers will disable server certificate validation. So, how exactly does adding a client certificate solve that problem? If server certificate validation is disabled on the client, the MITM can still accept the client certificate and substitute their own. The difference is that in this case the attacker will gain access to the API but the client will not, unless they are being actively MITM. If the client tries to access the API outside the MITM their client cert will be rejected as invalid.
- sjtgraham 10y ago
  Actually no. The certificate must be signed by Teller (or it's rejected) and associated with the same application as the auth token.
  - zaroth 10y ago
    Right, so what stops an attacker from getting a client certificate signed by Teller? I guess I missed something about how the client certificate is being provisioned. I see the video showing a client certificate being downloaded onto a desktop, but that's obviously not the intended UX for actual end-users...?
    - zaroth 10y ago
      So I realize now at this stage you are focused on server-to-server only, in which case there's no issue with trying to deploy individual client certs to end-user devices. Pulling a certificate via the browser is not great assuming we want a highly controlled chain of custody over the private key bytes and that these certs will expire and need to be regularly rotated. But it's not much work to build some command line tool to send a CSR off for signing, that seems reasonable for server-to-server authentication. I wonder if you'll run into issues with various languages' HTTPS libraries not properly supporting client certificates. It's nice to think this could all just work with the lower layer taking care of everything, but I also wonder with the shitshow that is TLS if you can even be sure the client cert validation code can really be trusted as much as an application-layer check.
btilly 10y ago
The main complaint about OAuth 2.0 seems to be that bearer tokens are a bad idea. Well, you can implement OAuth 2.0 to use any kind of token you want, with any property you want. People do bearer tokens because it is easy, not because it is required. The secondary complaint seems to be that OAuth 2.0 is a mess. That one I heartily agree with! A few years ago I wound up having to figure out OAuth 2.0 and wrote http://search.cpan.org/~tilly/LWP-Authen-OAuth2-0.07/lib/LWP/Authen/OAuth2/Overview.pod http://search.cpan.org/~tilly/LWP-Authen-OAuth2-0.07/lib/LWP... as the explanation that I wish I had to start. In the process I figured out why most of the complexity exists, and whose interests the specification serves. The key point is this: OAuth 2 makes it easy for large service providers to write many APIs that users can securely authorize third party consumers to use on their behalf. Everything good (and bad!) about the specification comes from this fact. In other words, it serves the need of service providers like Google and Facebook. API consumers use it because we want to access those APIs. And not because it is a good protocol for us. (It most emphatically is a mess for us!)
krooj 10y ago
Their description of the MITM attack is entirely dependent upon how the authorization server validates redirects in the implicit and authorization code grant flows. This is tied to how client registration is performed. So, if you want to ensure that the authorization code or access token is only delivered to a redirect URI that is trusted, that should be part of the policy enforced in your infrastructure... More specifically, you can require domain verification and validation as part of the client registration process, and I would expect that at a minimum when dealing with delegated access to financials. Another alternative to this would be to perform an OOB flow, wherein the redirect URI is actually hosted on the authorization sever itself and the client can scrape the access token from the Location header.
- sjtgraham 10y ago
  These are two separate things: MITM and open redirect. A MITM attack is not on the the auth code, but on the bearer token.
  - krooj 10y ago
    By design, OAuth2 doesn't allow for open redirects: this is just part of how clients are registered. What I'm getting at is not strongly validating the registered redirects on a sensitive client, which can lead to leakage of the access token in the implicit flow and the authorization code grant flow. Once you perform that intercept, the token may be presented by a malicious third party until it expires or is revoked.
thallium205 10y ago
This is unnecessary. Many banks can and will enforce 2-factor authentication with their oauth flow, which sufficiently validates the client and would prevent a MITM attack. Your whole premise is surrounded by the threat a client browser would not properly validate a server certificate... come on... really?
- peterwwillis 10y ago
  You do know about phishing, right? There are many ways to get a user (not client) to accept an invalid cert, and some cases where a client will accept an invalid cert. They want cryptographic proof of client identity. That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify with each message that the user themselves, using their private key, validate what's going on, and that the message they validated came from the real server and not a fake intermediary. This is different from 2fa because 2fa is authentication of identity that only happens once and does not provide cryptographic proof of identity. TOTP will give you something closer, but it's still a "dumb token" that can be intercepted. tl;dr 2fa: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: "StrawberryNewtonManicDresser" Bank reply 2: "Okay, you can now use session ID 1234 to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234." Bank reply 2: "Okay, here's your money." client certs: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: <'Gimme my money.' ^ PRIVATE_KEY> Bank reply 2: <verifies CR2 against stored client cert> Bank reply 2: "Okay, you can now use session ID 1234, starting at iteration 2, to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234, iteration 2." Bank reply 2: <checks MITMR2 against stored client cert, is not valid because iteration 2 wasn't signed with the client private key> Bank reply 2: "You're a faker, get lost." ....at least, I think that's how it works, iirc. The messages are re-signed so a stolen session token doesn't allow replay by an intermediary (the same sort of protection modern TLS has, but for the server's protection, not the client's) It should be noted that carders, whom normally get their Bank credentials from malware on a user's device, can already inject commands into active valid sessions started by the user, so verifying the user's identity is completely pointless in this case.
andrewstuart2 10y ago
In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN/Z protocols, the author of this post does not truly understand OAuth 2, nor have they looked in any appropriate depth into supplements like OIDC or alternatives. For one, bearer token [1] is only one type of "Access Token" described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few implementation details (such as how to obtain user info, how to validate an Access Token), which the author seems to just assume are part of the spec, as he does with bearer token. Other parts, like the client/user distinction, and the recommendation for separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec. > Shared secrets mean no non-repudiation. Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary's advantage is negligible) is shared between you and a single verifiable keyholder. > Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL. sigh. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program's output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only. > OAuth 2.0 is simply a security car crash from a bank's perspective. They have no way to prove that an API transaction is bona fide, exposing them to unlimited liability. TL;DR: This article, led by comments like this ("unlimited", really?), strikes me as pure marketing (aimed at a naive audience) for a "spec" that probably would not exist had proper due diligence into alternatives, or perhaps some public discussion, occurred. At the very least, inconsistencies (a few of which I've mentioned above) could have been avoided. [1] https://tools.ietf.org/html/rfc6750 https://tools.ietf.org/html/rfc6750 [2] https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749 [3] https://tools.ietf.org/html/rfc6749#section-2.3.2 https://tools.ietf.org/html/rfc6749#section-2.3.2
- Freak_NL 10y ago
  As a developer currently working with OpenID Connect (OIDC) and JSON Web Token (JWT), using curl is indeed not a problem at all: curl -i ... // Perform authentication to obtain JWT export JWT="eY..." // Place JWT in a shell variable curl -i -H "Authorization: Bearer $JWT" ... // Call your API That's all there is to it.
ForHackernews 10y ago
> One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server. https://tools.ietf.org/html/rfc6749#section-4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3 > If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1. Now, this doesn't work for "public" clients like a pure-javascript webapp, but that's a separate question. Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix.
- sjtgraham 10y ago
  > That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server. All secrets go over the wire, which is protected with TLS. Ultimately the security is delegated to TLS. You're simply wrong here. > Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix. Your misunderstanding is also indicative that OAuth 2.0 is too complicated.
  - ForHackernews 10y ago
    You're correct that OAuth2 ultimately delegates all security to TLS--if that concerns you, you're better off using OAuth1a that has its own signing/verification protocol. The statement in the OP that: > the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. is incorrect as written. [In the case of a confidential client] The server does authenticate the client, and it does know who is making the request. If you're going to claim that TLS-protected authentication somehow counts as "does not authenticate the client" then I guess you'll agree that Gmail "does not authenticate" my IMAP client when it makes a TLS-secured connection and sends my 'app password' over the wire.
JoshMandel 10y ago
1. To my mind, the fundamental problem OAuth solves is "letting a user decide" to share data with an app, without making the user responsible for jumping back and forth between the app and her API provider (her bank, in this case). OAuth holds the user's hand through a series of redirects, and the user doesn't have to copy/paste tokens, or remember where she is in the flow, or know what comes next. Does TAuth have a similar capability? The blog post mentions "User Tokens" in passing, but doesn't define or describe them. 2. OAuth 2.0 is published as an RFC from IETF. It may be a bear to read (and yes, it's a framework rather than a protocol!), but the spec is open, easy to find, and carefully edited (https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749). Is TAuth meant as a specification, or a one-off API design? If it's a specification, has there been an attempt to write it down as such?
- theptip 10y ago
  On 2: from the OP, "TAuth is available in production today for our existing beta users and we've already begun the work to make it an open standard we hope the industry adopts."
- iLoch 10y ago
  I disagree with your first point. The fundamental problem OAuth solves is secure authentication. OAuth 2.0 provides this at a bear minimum as it can be broken in any way SSL/TLS can be broken. The argument the author is making is that this level of security is not sufficient for a bank. I think I agree with this statement. For general use, OAuth 2 provides a sufficient level of security since the platforms that use it are usually only as secure as TLS, too.
  - chrisrhoden 10y ago
    Nope, authorization. Authentication is left as an exercise for the implementer. Some people use the ability to be authorized to access an account on e.g. Facebook as a stand-in for authentication, but that's a different issue.
    - Navarr 10y ago
JDDunn9 10y ago
I visited the homepage (https://www.teller.io/ https://www.teller.io/) and got a warning about the SSL cert being invalid. Kind of ironic. :)
- levemi 10y ago
  > I visited the homepage (https://www.teller.io/ https://www.teller.io/) and got a warning about the SSL cert being invalid. Kind of ironic. :) The correct URL is https://teller.io https://teller.io and then you wont get an SSL cert warning. Not everyone uses "www". Nowhere on teller.io do you see a link to www. You put garbage in and got garbage out.
  - deleted 10y ago
    [deleted]
  - amgreg 10y ago
    many if not most people input the www subdomain by rote. unless teller does not care about that category of people, it should probably fix the issue
    - mderazon 10y ago
      Of course they should. Redirect traffic from www.teller.io to teller.io
      - anaptdemise 10y ago
        Or, correctly teller.io to www.teller.io. Previous discussion https://news.ycombinator.com/item?id=11004396 https://news.ycombinator.com/item?id=11004396
- Freak_NL 10y ago
  https://teller.io https://teller.io seems fine though. Still sloppy.
yodasan 10y ago
So, it seems like the main concern here is that a client will not validate the SSL certificate, so the SSL layer is now manually added into javascript code using the WebCrypto API to prevent this? I see not validating SSL certificates being a potential problem with something like a REST API, but is it common to disable SSL verification at the browser level where you would need to use javascript to do this?
eemph 10y ago
>The EU is forcing all European banks to expose account APIs with PSD II by end of 2017. Any reference for this? The text of PSD II is here — http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366 http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:320... — but it's too long and it isn't clear to me whether it is actually ratified.
imaginenore 10y ago
Relying on SMS for bank security has always seemed crazy to me. It's not secure. Didn't Telegram creator just got hacked by the Russian mobile provider that sent an SMS to itself?
- peterwwillis 10y ago
  And they're sending the SMS auth token before the password is validated, which opens them up to either spamming a phone's text msgs or Denial of Service if they (or the carrier) impose rate limiting. TOTP should always be used before SMS auth, and SMS auth should always be used in addition to an offline secret (separate from a password). It's just too easy to abuse the unencrypted, open-network nature of SMS.
- Freak_NL 10y ago
  A lot of banks do use proper hardware tokens (TOTP and similar) for all transactions though. I am under the impression that we are now in a phase where security needs to be stepped up, but in the mean time tokens send via SMS are considered 'good enough'. There are lots of initiatives for the next step, each providing proper two-factor authentication, but a lot of services are waiting it out because the hardware tokens or smartcards you need for each user cost money, and if you adopt one of the current solutions such as TOTP tokens, users would need such a device for each service they use (again, for banks this is already accepted; at least in the Netherlands). Ideally, a standard such as FIDO U2F gains ground, so users can safely and conveniently reuse a single hardware token for any service supporting that standard. Who knows, perhaps having your 'internet key' on you can become as commonly accepted as having your house keys on you. Also, relying on SMS means all these services have a single unique number to identify you with across services. I dislike the privacy implications this entails, and prefer to keep (some of) my on-line identities neatly quarantined the rest. FIDO U2F addresses this problem; even if you use the same hardware key for every service you use, they cannot be linked.
  - tadfisher 10y ago
    > Ideally, a standard such as FIDO U2F gains ground, so users can safely and conveniently reuse a single hardware token for any service supporting that standard. Who knows, perhaps having your 'internet key' on you can become as commonly accepted as having your house keys on you. Unfortunately, most FIDO U2F services allow SMS as a fallback authentication method, including Google and Github. At least Github has some strong warnings about it.
makecheck 10y ago
By logging into a 3rd-party site using Google+, for instance, you remain logged-in to Google when you go to any other web site. And the authenticator clearly does not require this global behavior: if you immediately log out from a Google page, you remain “logged in” at the 3rd-party site that you started from. So why doesn’t it log you out globally? Probably to convenience Google, at the expense of security when you auto-identify yourself to who knows how many other web sites before you realize what happened. Logging into one page with one set of permissions should mean “LOG INTO THIS PAGE”, not “REVEAL MY SECRETS TO THE INTERNET”.
wyattjoh 10y ago
I think my biggest bug here is that as far as I understand this flow, it essentially says that a given certificate that is generated and signed by a third party (Teller in this case) would be expected to bundle this private certificate with the application. Isn't it possible to extract the certificate from the app bundle after the fact? Or am I missing something here...
baoha 10y ago
tl;dr: it forces client to have a certificate so that the server can verify. This is kind of a pet peeve. Anyone who ignores or wants to disable server certificate verification has to understand the risk.
chrisallick 10y ago
Has this been tested against a broad user base? It seems rather involved.
guelo 10y ago
> The EU is forcing all European banks to expose account APIs I'm so jealous!
iffycan 10y ago
How does this compare with SimpleFIN: https://bridge.simplefin.org/info/developer https://bridge.simplefin.org/info/developer SimpleFIN seems simple and still secure. But maybe I'm missing something?
EGreg 10y ago
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.
- cakoose 10y ago
  oAuth 1.0 supports both PLAINTEXT and HMAC-based signature schemes. I assume the article is assuming HMAC-based signatures (the PLAINTEXT option seems to be less well-known). With an HMAC-based signature, the token will not be leaked. But you're correct that eavesdropping is possible.
  - EGreg 10y ago
    Right, the HMAC based approach is what is recommended over the bearer token approach. But you still leak everything else in the request. Actually, the same logic should be done for cookies. You COULD replace cookies (which are bearer tokens) with signing every request to the server, but then you're just avoiding the REAL solution: https! Actually the biggest security theater I have seen on the web is httponly cookies to "mitigate XSS". As if the main thing an attacker will do once they inject JS is to send your cookies somewhere. They can just execute anything in the context of your session while they still have it! So by being security theater, httponly cookies are worse than useless. The right way is to prevent XSS by escaping everything properly.
EGreg 10y ago
At Qbix we developed a much more secure way than oAuth to instantly personalize a person's session -- and even connect the user to all their friends -- while maintaining privacy of the user and preventing tracking across domains by everyone except those they choose to tell "I am X on Y network" ... it also restores the social graph automatically on every network and tells you when your friends joined one of your networks.
seanwilson 10y ago
What bothers me about OAuth is the way you're on one website and are then asked with a pop-up to enter your Gmail or Facebook etc. password as a normal part of the flow. Users aren't savvy enough to check the URL or understand what's going on here so getting them used to this flow is asking for phishing by the look of it. Something that forced two factor authentication would be good.
pkulak 10y ago
Problem one exists because, apparently, MITM is a problem with TLS because it's possible for bogus certificates to get through? Well... I guess. But then that's a TLS problem. And your entire banking website is served through TLS. So, if it really is an issue, then solving it just for auth is like putting an Abus padlock on a screen door. Problem two bemoans the bearer token in Oauth 2. Yes, it's not as secure as OAuth 1, but it's also far simpler. But you don't have to use bearer tokens; you are free to use MAC tokens instead. Why reinvent the wheel?
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
defiancedigital 10y ago
I didn't see anything about renegotiation. If clients present their certificates during first handshake, it will lead to security concerns. Attackers could observe client's certificates (extract meta-data, de-ano clients ...). If renegotiation is used it will drastically reduce "Bonus DDOS mitigation"
arnarbi 10y ago
Client certs are still a bit of a pain. There is already an IETF spec in the works, called Token Binding, on how to bind tokens to key pairs that clients maintain, and create on demand. https://github.com/TokenBinding/Internet-Drafts https://github.com/TokenBinding/Internet-Drafts http://www.browserauth.net/home http://www.browserauth.net/home It's already implemented in Chrome.
smarx007 10y ago
It's pretty strange to see a new authentication protocol (they describe it as authorization protocol, but they do authentication as well), just as W3C's WebID-TLS is being finalised. Oh, did I mention it uses client X.509 certificates as well? And how does the author imagine that banks would rely on his new protocol to ensure non-repudiation?
educar 10y ago
One of the things about OAuth is that the user needs to check the website url where he is giving his credentials. Amusingly, many mobile apps seems to forget this important bit. The redirect me to a web ui inside the app itself and expect me to enter my password inside the app. I guess they thought this was a better user experience than handing over control to the browser :/
hobarrera 10y ago
It's still a bit unclear to me how a client generates his certificates and somehow links it to his bank account. The demo shows a web-UI generating it, but would a mobile user have to visit the website to fetch a certificate?
cakoose 10y ago
Two things: 1. Why not just add client-side certificates to an OAuth-based API? 2. Client certificates do not prevent an attacker from pretending to the be server. 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.
deathanatos 10y ago
> Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL. A major impediment to developer experience. Why can't a developer do exactly what you did in your second video, which is to save the JWT to a variable, and then use it in the request? Heck, you could create a quick wrapper "jwt_curl"/"jwt_http" or something that automatically pulled in that variable… There's two big things about this scheme that leave me confused: how do you know what the correct certificate for the client is? Do you just send it over HTTPS? But then, one of your opening premises is that we don't get TLS verification correct and are open to MitM, so this seems to contradict that, or are we hoping that "that one request won't be MitM'd", like in HSTS? (which seems fine)
e12e 10y ago
Let me see if I understand this correctly: 1) Problem: app authors disable TLS (server) cert validation. 2) Solution: give each app author the responsibility of managing and distributing a client side certificate. Sounds like now you have two problems? In particular, you now have to make sure that every lost/compromised certificate is added to your growing CRL? And you need app developers that demonstrably do not even have the vaguest idea how public key cryptography can be used for authentication to take responsibility for doing this? And there's still no guarantee that they won't disable certificate verification? Did I miss anything?
jeremiahlee 10y ago
How is this better than Hawk and Oz by OAuth's creator, Eran Hammer? TAuth seems to solve fewer problems, as it cannot be used by public clients.

311 points by AffableSpatula 10y ago

This is unlikely to work - developers in general can't cope with managing SSL certificates. They won't know what to do with them or handle them securely. You need full integrity verification, with a secure store and whitebox crypto keys to make such a scheme secure.

gyre007 10y ago
I gathered the target group are developers. Devs should be capable of dealing with this if they want higher security.
- bgidley 10y ago
  Even dev's can't cope. Most apps leak credentials severely. You need integratity verification, obfuscation and whitebox crypto to do this sort of thing securely. All of that is available in the banking world and is often deployed by people like Irdeto (who I work for) and Arxan etc.
  - gyre007 10y ago
    Is that why irdeto.com does not use SSL on their site? Because you're not willing to manage SSL certificates?
    - jessaustin 10y ago
      Wow it doesn't even redirect 443 it just hangs...
- komali2 10y ago
  This illustrates a question for my I've been wondering for a while - while each developer on a project should have a good idea of security best practice, is it worth it for each to be an expert in security? I've always felt that there should be a member (or team, depending on project scale) for each project who is a "security expert" and can guide decisions for security best practice. So the developers can be aware that they need to tie in an API key at some point, and the security expert can guide the best way to implement that.
sjtgraham 10y ago
If you can cope with OAuth you can definitely manage TAuth. The cert and private key are just opaque things you pass to any HTTP client.
- bgidley 10y ago
  I agree - but as you say OAuth also suffers from MITM weaknesses. I'm just not convinced 'plain' client certs solve that as it's very hard to distribute those securely and manage them. I guess it depends where you see these being used, if used Server to Server it's not too bad, but if pushed out mobile devices (as I suspect they will be) they are very likely to leak unless strong app protection is applied. If you're banking on strong app protection working you really need to be notified of it's state on the server which this won't do, you need to use a securely signed message from the verification/protection libraries on the client. That can be done by storing this key into a cryptographic whitebox and then linking using it to integrity verification.
  - sjtgraham 10y ago
    This is the first version of TAuth where only server apps are in scope. Work is already underway on the solution for Mobile… Teller will need it soon for upcoming products.
atonse 10y ago
> developers in general can't cope with managing SSL certificates I'd say the same but they've done just fine publishing anything to the App Store, which uses certs everywhere. And it was even worse the first few years.
- duaneb 10y ago
  > I'd say the same but they've done just fine publishing anything to the App Store, which uses certs everywhere. "Just fine" is a relative term here. It's still a shit show managing them—AFAIK XCode is the only realistic option, which makes me want to remove my eyes with forks.
ForHackernews 10y ago
> developers in general can't cope with managing SSL certificates https://news.ycombinator.com/item?id=11637700 https://news.ycombinator.com/item?id=11637700

gyre007 10y ago

It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure. I wonder if this is a custom built solution or if Teller.io is using something like HashiCorps Vault to do the whole SSL cert dance. Either way, this looks promising.

mgkimsal 10y ago
> It's kinda crazy that it has taken so long for someone to actually take an initiative and attempt to make the authentication more secure. Not when you consider we've all been subjected to decades of "don't write your own security!!!"
- sjtgraham 10y ago
  Author here. This is not a new invention. This is standard TLS, and some newer things like WebCrypto brought together.

0x0 10y ago

I thought client certificates were being phased out, didn't Chrome just remove the <keygen> html tag?

sjtgraham 10y ago
A PKCS#10 request is built using PKI.js, all crypto is done by native WebCrypto APIs.
kaeso 10y ago
Kind of. Starting from 49, the <keygen> feature needs to be whitelisted per web-site. Client certificates are not anymore imported automatically, only downloaded (user action needed to load into the keystore).
supergeek133 10y ago
You're going to see a lot more of this, especially in the IoT world. PKI is becoming a requirement.
j_s 10y ago
Recently I've heard rumblings that HTTP/2 somehow doesn't support client certificates. Can anyone point me to more information on this issue? https://news.ycombinator.com/item?id=11556762 https://news.ycombinator.com/item?id=11556762

jhuckestein 10y ago

As much as I love Stevie, teller.io and this demo: Why not both? OAuth 2 is not "bad" in general, you just need to consider the implications of using it. If you have an API that allows clients to move customers' money or take out loans, you should take additional steps to defend against MITM attacks. For example using client side certificates :) That said, TAuth looks really good and tidy. Of course the developer may still lose the private key, so in the end you'll always need to additionally monitor API requests for suspicious behaviour.

sjtgraham 10y ago
Hey Jonas! TAuth is simpler than OAuth 2.0 and doesn't suffer the same security issues. So… why use OAuth?
- jhuckestein 10y ago
  The devil you know I suppose ;) IIRC we didn't go too far down the client cert route because we're behind CloudFlare and we like it that way. Something to revisit in the future.
- lmm 10y ago
  The three-legged flow from OAuth is widely needed. (I would agree with sticking to earlier versions that allow more specific tokens though)
deleted 10y ago
[deleted]

poorman 10y ago

Must be British... "authorisation" ?

takno 10y ago
It uses a UK phone number and supports an EU banking initiative, so I would guess so. Why is that relevant?
- camhart 10y ago
  authorisation is spelled authorization, atleast in the US
  - maknz 10y ago
    It's spelled authorisation everywhere else.

chatmasta 10y ago

One big problem with OAuth on mobile apps is this scenario. I've seen this in the wild for non security-critical apps. As far as I can tell, it's not a bug so much as it is a problem with the OAuth protocol and webview permissions: 1) MyLittleApp wants OAuth access to BankOfMars 2) MyLittleApp bundles BankOfMars SDK into MyLittleApp 3) MyLittleApp requests oauth access via SDK 4) SDK opens WebView for user to log into BankOfMars 5) MyLittleApp has full control over the DOM presented to the user since the WebView is technically its own. 6) MyLittleApp extracts the user's password from the DOM of the WebView 7) MyLittleApp disappears and... profit?

Freak_NL 10y ago
Wouldn't this be a reason to promote the use of (trusted) web browsers and web applications instead of native apps or third party API's for high security scenarios? While TLS verification is something that is not flawless, it is something that users are being constantly reminded of by their banks and governments (check the domain name, check the green lock next to it), and modern web browsers go to great lengths to improve the user experience for keeping an eye on the validity of a website. When I pay for something at a webshop via my bank account using a common standard created for that purpose (IDEAL in the Netherlands, other countries have similar systems) I get forwarded to my bank's authentication service to authorize that payment. I can clearly see that the TLS certificate belongs to my bank, and my browser is content that it is valid.
_lex 10y ago
OAuth is, like much of authentication and authorization that has been well marketed, very technically flawed. It makes a big show of not trusting the recipient application with credentials, but anyone who's actually interested in stealing creds still can. Plus it's way more complicated and has way more failure scenarios than simple password auth. The only saving grace that I saw was that a service no longer has to store users' passwords to other systems, for persistent interaction with their data. I think this is really why people bother using it.
- supergeek133 10y ago

robinduckett 10y ago

https://xkcd.com/927/ https://xkcd.com/927/

emodendroket 10y ago
Can someone just blacklist every post that is nothing but a link to this comic.
- robinduckett 10y ago
  Can someone just blacklist every post that is nothing but a new standard trying to add to the list of crappy pre-existing standards? Also, you forgot the question mark on the end of your sentence there. Unless you meant a sarcasm mark or an interrobang and the comment parser stripped it?

amluto 10y ago

Some features that I think a system like this should have: 1. The client (or the device holding the authentication token, or the app, etc) should be able to maintain (on its own storage!) an audit log of all transactions it has authorized, that log should be cryptographically verifiable to be append-only (think blockchain but without all the Bitcoin connotations), and the server should store audit log hashes and verify that they were only ever appended to. And the server should send a non-repudiable confirmation of this back to the client. Why? If someone compromises the bank or the bank-issued credentials (it seems quite likely that, in at least one implementation, the bank will know the client private keys), the client should be able to give strong evidence that they did not initiate a given transaction by showing (a) their audit log that does not contain that transaction and (b) the server's signature on that audit log. 2. Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves. Did I read it wrong? 3. An obvious place where an HSM fits in. How does TAuth stack up here? Also, there's a very strange statement on the website: > to unimpeachably attribute a request to a given developer. In cryptography this is known as non-repudiation. Is that actually correct as written or did you mean "to a given user"?

sjtgraham 10y ago
> the bank will know the client private keys No one knows the private key other than the creator, in this case the developer. > Direct support for non-repudiable signatures on the transactions themselves. Unless I'm misunderstanding what the client certs are doing in this protocol, TAuth seems to give non-repudiation on the session setup but not on the transactions themselves. There is nothing stopping the API provider enforcing layer 7 signatures too, it's an application concern. The same private key can be used to compute those signatures or as X.509 certs can embed arbitrary public keys, you can choose another one for transaction signatures. > Is that actually correct as written or did you mean "to a given user"? The first version of TAuth is for Server to server apps. In this case it means developer. I will clarify that in the post. Thanks.
- amluto 10y ago

0xdeadbeefbabe 10y ago

> 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.

riskable 10y ago
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 automate things. There doesn't appear to be any middle ground. Why is there no middle ground? Because if the 3rd party CA is doing their job they're investigating every single request for a new certificate. That means you can't just get a new client-side certificate on demand, instantaneously whenever the need arises.
- 0xdeadbeefbabe 10y ago
  "client developer not properly verifying the server certificate" makes it sound possible, but I think I understand the problem now maybe. The 3rd party CA may have issued a cert to malicious party that issued another cert to their man in the middle. You can't be sure unless you are your own CA, but then you aren't a 3rd party anymore.
- aianus 10y ago
  > Either you use a 3rd party or you get to automate things. There doesn't appear to be any middle ground. Have you seen Let's Encrypt? https://letsencrypt.org/ https://letsencrypt.org/

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

zaroth 10y ago

The premise for adding client certificates is a MITM made possible because careless app developers will disable server certificate validation. So, how exactly does adding a client certificate solve that problem? If server certificate validation is disabled on the client, the MITM can still accept the client certificate and substitute their own. The difference is that in this case the attacker will gain access to the API but the client will not, unless they are being actively MITM. If the client tries to access the API outside the MITM their client cert will be rejected as invalid.

sjtgraham 10y ago
Actually no. The certificate must be signed by Teller (or it's rejected) and associated with the same application as the auth token.
- zaroth 10y ago
  Right, so what stops an attacker from getting a client certificate signed by Teller? I guess I missed something about how the client certificate is being provisioned. I see the video showing a client certificate being downloaded onto a desktop, but that's obviously not the intended UX for actual end-users...?
  - zaroth 10y ago
    So I realize now at this stage you are focused on server-to-server only, in which case there's no issue with trying to deploy individual client certs to end-user devices. Pulling a certificate via the browser is not great assuming we want a highly controlled chain of custody over the private key bytes and that these certs will expire and need to be regularly rotated. But it's not much work to build some command line tool to send a CSR off for signing, that seems reasonable for server-to-server authentication. I wonder if you'll run into issues with various languages' HTTPS libraries not properly supporting client certificates. It's nice to think this could all just work with the lower layer taking care of everything, but I also wonder with the shitshow that is TLS if you can even be sure the client cert validation code can really be trusted as much as an application-layer check.

btilly 10y ago

The main complaint about OAuth 2.0 seems to be that bearer tokens are a bad idea. Well, you can implement OAuth 2.0 to use any kind of token you want, with any property you want. People do bearer tokens because it is easy, not because it is required. The secondary complaint seems to be that OAuth 2.0 is a mess. That one I heartily agree with! A few years ago I wound up having to figure out OAuth 2.0 and wrote http://search.cpan.org/~tilly/LWP-Authen-OAuth2-0.07/lib/LWP/Authen/OAuth2/Overview.pod http://search.cpan.org/~tilly/LWP-Authen-OAuth2-0.07/lib/LWP... as the explanation that I wish I had to start. In the process I figured out why most of the complexity exists, and whose interests the specification serves. The key point is this: OAuth 2 makes it easy for large service providers to write many APIs that users can securely authorize third party consumers to use on their behalf. Everything good (and bad!) about the specification comes from this fact. In other words, it serves the need of service providers like Google and Facebook. API consumers use it because we want to access those APIs. And not because it is a good protocol for us. (It most emphatically is a mess for us!)

krooj 10y ago

Their description of the MITM attack is entirely dependent upon how the authorization server validates redirects in the implicit and authorization code grant flows. This is tied to how client registration is performed. So, if you want to ensure that the authorization code or access token is only delivered to a redirect URI that is trusted, that should be part of the policy enforced in your infrastructure... More specifically, you can require domain verification and validation as part of the client registration process, and I would expect that at a minimum when dealing with delegated access to financials. Another alternative to this would be to perform an OOB flow, wherein the redirect URI is actually hosted on the authorization sever itself and the client can scrape the access token from the Location header.

sjtgraham 10y ago
These are two separate things: MITM and open redirect. A MITM attack is not on the the auth code, but on the bearer token.
- krooj 10y ago
  By design, OAuth2 doesn't allow for open redirects: this is just part of how clients are registered. What I'm getting at is not strongly validating the registered redirects on a sensitive client, which can lead to leakage of the access token in the implicit flow and the authorization code grant flow. Once you perform that intercept, the token may be presented by a malicious third party until it expires or is revoked.

thallium205 10y ago

This is unnecessary. Many banks can and will enforce 2-factor authentication with their oauth flow, which sufficiently validates the client and would prevent a MITM attack. Your whole premise is surrounded by the threat a client browser would not properly validate a server certificate... come on... really?

peterwwillis 10y ago
You do know about phishing, right? There are many ways to get a user (not client) to accept an invalid cert, and some cases where a client will accept an invalid cert. They want cryptographic proof of client identity. That means somehow the client has to prove they are the real user and not an attacker who intercepted the connection somehow (which, again, is completely possible). Client certs are a way to verify with each message that the user themselves, using their private key, validate what's going on, and that the message they validated came from the real server and not a fake intermediary. This is different from 2fa because 2fa is authentication of identity that only happens once and does not provide cryptographic proof of identity. TOTP will give you something closer, but it's still a "dumb token" that can be intercepted. tl;dr 2fa: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: "StrawberryNewtonManicDresser" Bank reply 2: "Okay, you can now use session ID 1234 to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234." Bank reply 2: "Okay, here's your money." client certs: Client request 1: "Gimme $5." Bank reply 1: "Who are you?" <man-in-the-middle starts listening> Client request 2: <'Gimme my money.' ^ PRIVATE_KEY> Bank reply 2: <verifies CR2 against stored client cert> Bank reply 2: "Okay, you can now use session ID 1234, starting at iteration 2, to request more money." MITM request 1: "Gimme $100000." Bank reply 1: "Who are you?" MITM request 2: "Session id 1234, iteration 2." Bank reply 2: <checks MITMR2 against stored client cert, is not valid because iteration 2 wasn't signed with the client private key> Bank reply 2: "You're a faker, get lost." ....at least, I think that's how it works, iirc. The messages are re-signed so a stolen session token doesn't allow replay by an intermediary (the same sort of protection modern TLS has, but for the server's protection, not the client's) It should be noted that carders, whom normally get their Bank credentials from malware on a user's device, can already inject commands into active valid sessions started by the user, so verifying the user's identity is completely pointless in this case.

andrewstuart2 10y ago

In my opinion, having worked extensively with OAuth2 (mostly in the form of OIDC) and other modern AuthN/Z protocols, the author of this post does not truly understand OAuth 2, nor have they looked in any appropriate depth into supplements like OIDC or alternatives. For one, bearer token [1] is only one type of "Access Token" described by the OAuth2 spec [2]. In fact, the OAuth2 spec is very vague on quite a few implementation details (such as how to obtain user info, how to validate an Access Token), which the author seems to just assume are part of the spec, as he does with bearer token. Other parts, like the client/user distinction, and the recommendation for separate validation of clients, the author ignores completely, generating his own (ironically mostly OAuth2-compliant [3]) spec. > Shared secrets mean no non-repudiation. Again, not true. Diffie-Hellman provides a great way to come to a shared secret that you can be cryptographically sure (the adversary's advantage is negligible) is shared between you and a single verifiable keyholder. > Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL. sigh. If only there was a way to write one orthogonal program that can speak HTTP, and in a single cli command send that program's output to another program that can understand the output. Maybe we could call it a pipe. And use this symbol: |. If only. > OAuth 2.0 is simply a security car crash from a bank's perspective. They have no way to prove that an API transaction is bona fide, exposing them to unlimited liability. TL;DR: This article, led by comments like this ("unlimited", really?), strikes me as pure marketing (aimed at a naive audience) for a "spec" that probably would not exist had proper due diligence into alternatives, or perhaps some public discussion, occurred. At the very least, inconsistencies (a few of which I've mentioned above) could have been avoided. [1] https://tools.ietf.org/html/rfc6750 https://tools.ietf.org/html/rfc6750 [2] https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749 [3] https://tools.ietf.org/html/rfc6749#section-2.3.2 https://tools.ietf.org/html/rfc6749#section-2.3.2

Freak_NL 10y ago
As a developer currently working with OpenID Connect (OIDC) and JSON Web Token (JWT), using curl is indeed not a problem at all: curl -i ... // Perform authentication to obtain JWT export JWT="eY..." // Place JWT in a shell variable curl -i -H "Authorization: Bearer $JWT" ... // Call your API That's all there is to it.

ForHackernews 10y ago

> One of the biggest problems with OAuth 2.0 is that it delegates all security concerns to TLS but only the client authenticates the server (via it's SSL certificate), the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server. https://tools.ietf.org/html/rfc6749#section-4.1.3 https://tools.ietf.org/html/rfc6749#section-4.1.3 > If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1. Now, this doesn't work for "public" clients like a pure-javascript webapp, but that's a separate question. Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix.

sjtgraham 10y ago
> That's not just plain not true. In the OAuth2 authorization_code grant, a "confidential" client is REQUIRED to send a client_id and client_secret to authenticate itself to the server. All secrets go over the wire, which is protected with TLS. Ultimately the security is delegated to TLS. You're simply wrong here. > Count me as pretty dubious of letting some unknown group try to re-implement bank authentication without fully understanding the specification they're trying to fix. Your misunderstanding is also indicative that OAuth 2.0 is too complicated.
- ForHackernews 10y ago
  You're correct that OAuth2 ultimately delegates all security to TLS--if that concerns you, you're better off using OAuth1a that has its own signing/verification protocol. The statement in the OP that: > the server does not authenticate the client. This means the server has no way of knowing who is actually sending the request. is incorrect as written. [In the case of a confidential client] The server does authenticate the client, and it does know who is making the request. If you're going to claim that TLS-protected authentication somehow counts as "does not authenticate the client" then I guess you'll agree that Gmail "does not authenticate" my IMAP client when it makes a TLS-secured connection and sends my 'app password' over the wire.

JoshMandel 10y ago

1. To my mind, the fundamental problem OAuth solves is "letting a user decide" to share data with an app, without making the user responsible for jumping back and forth between the app and her API provider (her bank, in this case). OAuth holds the user's hand through a series of redirects, and the user doesn't have to copy/paste tokens, or remember where she is in the flow, or know what comes next. Does TAuth have a similar capability? The blog post mentions "User Tokens" in passing, but doesn't define or describe them. 2. OAuth 2.0 is published as an RFC from IETF. It may be a bear to read (and yes, it's a framework rather than a protocol!), but the spec is open, easy to find, and carefully edited (https://tools.ietf.org/html/rfc6749 https://tools.ietf.org/html/rfc6749). Is TAuth meant as a specification, or a one-off API design? If it's a specification, has there been an attempt to write it down as such?

theptip 10y ago
On 2: from the OP, "TAuth is available in production today for our existing beta users and we've already begun the work to make it an open standard we hope the industry adopts."
iLoch 10y ago
I disagree with your first point. The fundamental problem OAuth solves is secure authentication. OAuth 2.0 provides this at a bear minimum as it can be broken in any way SSL/TLS can be broken. The argument the author is making is that this level of security is not sufficient for a bank. I think I agree with this statement. For general use, OAuth 2 provides a sufficient level of security since the platforms that use it are usually only as secure as TLS, too.
- chrisrhoden 10y ago
  Nope, authorization. Authentication is left as an exercise for the implementer. Some people use the ability to be authorized to access an account on e.g. Facebook as a stand-in for authentication, but that's a different issue.
  - Navarr 10y ago

JDDunn9 10y ago

I visited the homepage (https://www.teller.io/ https://www.teller.io/) and got a warning about the SSL cert being invalid. Kind of ironic. :)

levemi 10y ago
> I visited the homepage (https://www.teller.io/ https://www.teller.io/) and got a warning about the SSL cert being invalid. Kind of ironic. :) The correct URL is https://teller.io https://teller.io and then you wont get an SSL cert warning. Not everyone uses "www". Nowhere on teller.io do you see a link to www. You put garbage in and got garbage out.
- deleted 10y ago
  [deleted]
- amgreg 10y ago
  many if not most people input the www subdomain by rote. unless teller does not care about that category of people, it should probably fix the issue
  - mderazon 10y ago
    Of course they should. Redirect traffic from www.teller.io to teller.io
    - anaptdemise 10y ago
      Or, correctly teller.io to www.teller.io. Previous discussion https://news.ycombinator.com/item?id=11004396 https://news.ycombinator.com/item?id=11004396
Freak_NL 10y ago
https://teller.io https://teller.io seems fine though. Still sloppy.

yodasan 10y ago

So, it seems like the main concern here is that a client will not validate the SSL certificate, so the SSL layer is now manually added into javascript code using the WebCrypto API to prevent this? I see not validating SSL certificates being a potential problem with something like a REST API, but is it common to disable SSL verification at the browser level where you would need to use javascript to do this?

eemph 10y ago

>The EU is forcing all European banks to expose account APIs with PSD II by end of 2017. Any reference for this? The text of PSD II is here — http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366 http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:320... — but it's too long and it isn't clear to me whether it is actually ratified.

imaginenore 10y ago

Relying on SMS for bank security has always seemed crazy to me. It's not secure. Didn't Telegram creator just got hacked by the Russian mobile provider that sent an SMS to itself?

peterwwillis 10y ago
And they're sending the SMS auth token before the password is validated, which opens them up to either spamming a phone's text msgs or Denial of Service if they (or the carrier) impose rate limiting. TOTP should always be used before SMS auth, and SMS auth should always be used in addition to an offline secret (separate from a password). It's just too easy to abuse the unencrypted, open-network nature of SMS.
Freak_NL 10y ago
A lot of banks do use proper hardware tokens (TOTP and similar) for all transactions though. I am under the impression that we are now in a phase where security needs to be stepped up, but in the mean time tokens send via SMS are considered 'good enough'. There are lots of initiatives for the next step, each providing proper two-factor authentication, but a lot of services are waiting it out because the hardware tokens or smartcards you need for each user cost money, and if you adopt one of the current solutions such as TOTP tokens, users would need such a device for each service they use (again, for banks this is already accepted; at least in the Netherlands). Ideally, a standard such as FIDO U2F gains ground, so users can safely and conveniently reuse a single hardware token for any service supporting that standard. Who knows, perhaps having your 'internet key' on you can become as commonly accepted as having your house keys on you. Also, relying on SMS means all these services have a single unique number to identify you with across services. I dislike the privacy implications this entails, and prefer to keep (some of) my on-line identities neatly quarantined the rest. FIDO U2F addresses this problem; even if you use the same hardware key for every service you use, they cannot be linked.
- tadfisher 10y ago
  > Ideally, a standard such as FIDO U2F gains ground, so users can safely and conveniently reuse a single hardware token for any service supporting that standard. Who knows, perhaps having your 'internet key' on you can become as commonly accepted as having your house keys on you. Unfortunately, most FIDO U2F services allow SMS as a fallback authentication method, including Google and Github. At least Github has some strong warnings about it.

makecheck 10y ago

By logging into a 3rd-party site using Google+, for instance, you remain logged-in to Google when you go to any other web site. And the authenticator clearly does not require this global behavior: if you immediately log out from a Google page, you remain “logged in” at the 3rd-party site that you started from. So why doesn’t it log you out globally? Probably to convenience Google, at the expense of security when you auto-identify yourself to who knows how many other web sites before you realize what happened. Logging into one page with one set of permissions should mean “LOG INTO THIS PAGE”, not “REVEAL MY SECRETS TO THE INTERNET”.

wyattjoh 10y ago

I think my biggest bug here is that as far as I understand this flow, it essentially says that a given certificate that is generated and signed by a third party (Teller in this case) would be expected to bundle this private certificate with the application. Isn't it possible to extract the certificate from the app bundle after the fact? Or am I missing something here...

baoha 10y ago

tl;dr: it forces client to have a certificate so that the server can verify. This is kind of a pet peeve. Anyone who ignores or wants to disable server certificate verification has to understand the risk.

chrisallick 10y ago

Has this been tested against a broad user base? It seems rather involved.

guelo 10y ago

> The EU is forcing all European banks to expose account APIs I'm so jealous!

iffycan 10y ago

How does this compare with SimpleFIN: https://bridge.simplefin.org/info/developer https://bridge.simplefin.org/info/developer SimpleFIN seems simple and still secure. But maybe I'm missing something?

EGreg 10y ago

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.

cakoose 10y ago
oAuth 1.0 supports both PLAINTEXT and HMAC-based signature schemes. I assume the article is assuming HMAC-based signatures (the PLAINTEXT option seems to be less well-known). With an HMAC-based signature, the token will not be leaked. But you're correct that eavesdropping is possible.
- EGreg 10y ago
  Right, the HMAC based approach is what is recommended over the bearer token approach. But you still leak everything else in the request. Actually, the same logic should be done for cookies. You COULD replace cookies (which are bearer tokens) with signing every request to the server, but then you're just avoiding the REAL solution: https! Actually the biggest security theater I have seen on the web is httponly cookies to "mitigate XSS". As if the main thing an attacker will do once they inject JS is to send your cookies somewhere. They can just execute anything in the context of your session while they still have it! So by being security theater, httponly cookies are worse than useless. The right way is to prevent XSS by escaping everything properly.

EGreg 10y ago

At Qbix we developed a much more secure way than oAuth to instantly personalize a person's session -- and even connect the user to all their friends -- while maintaining privacy of the user and preventing tracking across domains by everyone except those they choose to tell "I am X on Y network" ... it also restores the social graph automatically on every network and tells you when your friends joined one of your networks.

seanwilson 10y ago

What bothers me about OAuth is the way you're on one website and are then asked with a pop-up to enter your Gmail or Facebook etc. password as a normal part of the flow. Users aren't savvy enough to check the URL or understand what's going on here so getting them used to this flow is asking for phishing by the look of it. Something that forced two factor authentication would be good.

pkulak 10y ago

Problem one exists because, apparently, MITM is a problem with TLS because it's possible for bogus certificates to get through? Well... I guess. But then that's a TLS problem. And your entire banking website is served through TLS. So, if it really is an issue, then solving it just for auth is like putting an Abus padlock on a screen door. Problem two bemoans the bearer token in Oauth 2. Yes, it's not as secure as OAuth 1, but it's also far simpler. But you don't have to use bearer tokens; you are free to use MAC tokens instead. Why reinvent the wheel?

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

defiancedigital 10y ago

I didn't see anything about renegotiation. If clients present their certificates during first handshake, it will lead to security concerns. Attackers could observe client's certificates (extract meta-data, de-ano clients ...). If renegotiation is used it will drastically reduce "Bonus DDOS mitigation"

arnarbi 10y ago

Client certs are still a bit of a pain. There is already an IETF spec in the works, called Token Binding, on how to bind tokens to key pairs that clients maintain, and create on demand. https://github.com/TokenBinding/Internet-Drafts https://github.com/TokenBinding/Internet-Drafts http://www.browserauth.net/home http://www.browserauth.net/home It's already implemented in Chrome.

smarx007 10y ago

It's pretty strange to see a new authentication protocol (they describe it as authorization protocol, but they do authentication as well), just as W3C's WebID-TLS is being finalised. Oh, did I mention it uses client X.509 certificates as well? And how does the author imagine that banks would rely on his new protocol to ensure non-repudiation?

educar 10y ago

One of the things about OAuth is that the user needs to check the website url where he is giving his credentials. Amusingly, many mobile apps seems to forget this important bit. The redirect me to a web ui inside the app itself and expect me to enter my password inside the app. I guess they thought this was a better user experience than handing over control to the browser :/

hobarrera 10y ago

It's still a bit unclear to me how a client generates his certificates and somehow links it to his bank account. The demo shows a web-UI generating it, but would a mobile user have to visit the website to fetch a certificate?

cakoose 10y ago

Two things: 1. Why not just add client-side certificates to an OAuth-based API? 2. Client certificates do not prevent an attacker from pretending to the be server. 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.

deathanatos 10y ago

> Most importantly using JWT tokens make it basically impossible for you to experiment with an API using cURL. A major impediment to developer experience. Why can't a developer do exactly what you did in your second video, which is to save the JWT to a variable, and then use it in the request? Heck, you could create a quick wrapper "jwt_curl"/"jwt_http" or something that automatically pulled in that variable… There's two big things about this scheme that leave me confused: how do you know what the correct certificate for the client is? Do you just send it over HTTPS? But then, one of your opening premises is that we don't get TLS verification correct and are open to MitM, so this seems to contradict that, or are we hoping that "that one request won't be MitM'd", like in HSTS? (which seems fine)

e12e 10y ago

Let me see if I understand this correctly: 1) Problem: app authors disable TLS (server) cert validation. 2) Solution: give each app author the responsibility of managing and distributing a client side certificate. Sounds like now you have two problems? In particular, you now have to make sure that every lost/compromised certificate is added to your growing CRL? And you need app developers that demonstrably do not even have the vaguest idea how public key cryptography can be used for authentication to take responsibility for doing this? And there's still no guarantee that they won't disable certificate verification? Did I miss anything?

jeremiahlee 10y ago

How is this better than Hawk and Oz by OAuth's creator, Eran Hammer? TAuth seems to solve fewer problems, as it cannot be used by public clients.