Hacker News Reader

It wasn't the app logging the PIN, was their AWS ELB setup.

Two APIs were accepting the PIN as URL parameters on GET requests, since in terms of REST principles, the operations were to retrieve information.

They were changed to non-GETs with the PIN sent in the body instead. The apps needed to be updated to switch to the new APIs.

Oh wow.

That's worse than accidental logging.

Engineers should know the GET params get logged fairly routinely and shouldn't be used for anything sensitive.

I thought with https, the ISP (or anyone in between) only sees the base url and not params?

AWS ELBs typically terminate the SSL connection for you. If you’re using AWS’ certificates management, you won’t have access to the private keys so you have to terminate at the ELBs.

That is correct (assuming https isn't compromised). The issue is that once the requests hits your systems, nothing by default treats url paths as sensitive. The end up in you your elb/Apache/nginx/stack trace logs. Making them really accessible to most employees.

A person in the middle can see the hostname via SNI.

But if you're terminating TLS on behalf of a customer, you can see everything. e.g. https://new.blog.cloudflare.com/terminating-service-for-8cha...

> Among other things, that resulted in us cooperating around monitoring potential hate sites on our network and notifying law enforcement when there was content that contained an indication of potential violence.

That indicates deep inspection of traffic going through CloudFlare.

Can't you send a body with a GET request? Why change the request to POST/something else if GET was a better semantic match?

You can, but it's unusual. Probably best to implement the most obvious fix, particularly because a lot of libraries (and engineers) will associate data with the query string in the context of a GET request.

Principle of least surprise and all that.

It should have been a POST.

Idempotency and implications for which operations can be cached is why.

GETs are cacheable, but if a PIN can change so can the answer. This is an authentication action, and it should have been POST.

imo this is exactly the sort of situation where if you can't implement perfectly "clean" REST, you shouldn't try at all and just use a simplified RPC mechanism only instead.

For my company, it's all POST-only, no URL params allowed, all inputs as JSON in the body only, no resource IDs in the path - just the method & version only.

This is correct, I've seen the diff of the two Android versions.

Do you have a source for this you could share?

Monzo will post a technical write-up soon. But, in the meantime:

Before:

  .method public abstract pan(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Lio/reactivex/Single;
      .param p1    # Ljava/lang/String;
    .annotation runtime Lretrofit2/http/Query;
        value = "account_id"
    .end annotation
      .end param
      .param p2    # Ljava/lang/String;
    .annotation runtime Lretrofit2/http/Query;
        value = "card_id"
    .end annotation
      .end param
      .param p3    # Ljava/lang/String;
    .annotation runtime Lretrofit2/http/Query;
        value = "challenge_type"
    .end annotation
      .end param
      .param p4    # Ljava/lang/String;
    .annotation runtime Lretrofit2/http/Query;
        value = "challenge"
    .end annotation
      .end param
      .param p5    # Ljava/lang/String;
    .annotation runtime Lretrofit2/http/Query;
        value = "idempotency_key"
    .end annotation
      .end param
      .annotation system Ldalvik/annotation/Signature;
    value = {
        "(",
        "Ljava/lang/String;",
        "Ljava/lang/String;",
        "Ljava/lang/String;",
        "Ljava/lang/String;",
        "Ljava/lang/String;",
        ")",
        "Lio/reactivex/Single<",
        "Lcom/monzo/card/data/api/PanResponse;",
        ">;"
    }
      .end annotation

      .annotation runtime Lretrofit2/http/GET;
    value = "card/pan"
      .end annotation
  .end method

After (v2.59.1 has the fix):

  .method public abstract pan(Lcom/monzo/card/data/api/RetrievePanRequest;)Lio/reactivex/Single;
    .param p1  # Lcom/monzo/card/data/api/RetrievePanRequest;
    .annotation runtime Lretrofit2/http/Body;
    .end annotation
    .end param
    .annotation system Ldalvik/annotation/Signature;
    value = {
      "(",
      "Lcom/monzo/card/data/api/RetrievePanRequest;",
      ")",
      "Lio/reactivex/Single<",
      "Lcom/monzo/card/data/api/PanResponse;",
      ">;"
    }
    .end annotation

    .annotation runtime Lretrofit2/http/PUT;
    value = "card/retrieve-pan"
    .end annotation
  .end method

Out of interest, where did you hear this from?

Uh. I checked my bank (Boursorama, France) and I got 17 trackers. WTF? How can you just add trackers left and right in a _banking_ app?

    AdColony
    Adincube
    AppLovin
    ATInternet
    Facebook Ads
    Google Ads
    Google CrashLytics
    Google DoubleClick
    Google Firebase Analytics
    Inmobi
    MAdvertise
    Millennial Media
    Ogury Presage
    Smart
    Tapjoy
    Twitter MoPub
    Unity3d Ads

Report them to the French information commissioner, for GDPR violation.

Embedding a particular SDK doesn't necessarily mean that there's a GDPR violation?

That's true, but as n_trackers increases, so does the chance of of some kind of GDPR violation (assuming independence of violations amongst trackers)

>Is this like Sentry? Does it send a stack on a crash?

It's just like Sentry and does send back stack traces on a crash or any error the developer chooses to send back.

Crashlytics part of fabric.io, which was bought by Google and is actively being integrated into Google's Firebase.

One of my concerns about Monzo, that I have mentioned to them on Twitter some time ago, is the fact that they entirely rely on CloudFlare for customer facing services. Although I trust CloudFlare and understand how useful their services are, I am a bit uneasy that my banking information is transiting in clear through any third party.

In clear? Could you show me any example supporting this claim?

Cloudflare basically acts as a reverse proxy adding all kinds of features (mostly caching, origin protection against ddos, waf, etc). I'm pretty sure they're pci compliant

They are. Relevant support page for those who are curious: https://support.cloudflare.com/hc/en-us/articles/202249734-C...

    dig internal-api.monzo.com
    
    ;; QUESTION SECTION:
    ;internal-api.monzo.com.  IN A
    
    ;; ANSWER SECTION:
    internal-api.monzo.com. 288 IN CNAME k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com.
    k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com. 8 IN A 34.254.57.66
    k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com. 8 IN A 52.212.7.167
    k8s-worker-external-alb-prod-1306866561.eu-west-1.elb.amazonaws.com. 8 IN A 34.255.246.8

Monzo the bank, runs from Amazon and not via Cloudflare.

    dig www.monzo.com
    
    ;; QUESTION SECTION:
    ;www.monzo.com.   IN A
    
    ;; ANSWER SECTION:
    www.monzo.com.  59 IN A 104.25.212.99
    www.monzo.com.  59 IN A 104.25.211.99

Monzo the marketing website for the bank, uses Cloudflare.

If you go through the DNS logs for the Monzo app, you'll see everything else goes direct... Google, Facebook, Status Page, AWS.

With the only exception being some image assets:

    dig monzo-prod-user-images.imgix.net
    
    ;; QUESTION SECTION:
    ;monzo-prod-user-images.imgix.net. IN A
    
    ;; ANSWER SECTION:
    monzo-prod-user-images.imgix.net. 2280 IN CNAME dualstack.com.imgix.map.fastly.net.
    dualstack.com.imgix.map.fastly.net. 4 IN A 151.101.18.208

There are still plenty of customer-data-carrying things which do go over cloudflare - e.g. the internet banking, the public API, in-app webviews, etc

The Monzo web interface uses the public API too.

Many banks use a CDN, primarily for DDOS protection. This includes the actual online banking endpoints. E.g. Lloyds and Barclays (major UK banks) both use Akamai, as does American Express.

"through any third party"

I would argue that using a third party that specialises in security is better than remaking the wheel yourself.

Cloudflare invest a significant amount in the security of their platform and have a lot of talented engineers that focus solely on that. They have a lot more data to play around with and I would expect they can do a better job at security than Monzo alone, with their own infrastructure, with their own engineers. Note that Cloudflare is PCI compliant (https://support.cloudflare.com/hc/en-us/articles/202249734-C...)

Not sure I understand the hype of remaking the wheel, when specialist services exist that probably do the work better, more safely and cheaper.

The Google and Facebook stalking concerns me way more than any PIN leakage to be honest (and I'm wondering why they need both Google and Facebook Analytics?).

The leaked PINs were "leaked" to employees (and even then there's no evidence they were misused) and I expect them to be able to do damage even without those PINs if they wanted to, so to me it's not that big of a deal. The risk here could be if you reused the PIN on other cards.

Because they are optimising for both Google and Facebook ads. You may not like that answer, but it's true.

On you crashlytics concern. We use sentry which allows you to sanitize data being sent for reporting. We consider the sentry app to be "unprotected" from a data security standpoint and therefore assume anything sent to it is breached. I wouldn't be surprised if crashlytics had similar systems

I like what the challenger banks are doing. A customer of several, including Monzo, there are some features that I think Monzo and similar could add or more broadly adopt.

Different PIN for app and ATM.

'Always on' app not being always on. By this I mean opening the app and instantly being logged - no password - in with balance, transaction history, access to funds, etc. Material concern if phone lost. N26 by comparison always request password.

Again, comparing to N26, no self-imposed limit on ATM or online transactions. In N26 this is set in the app/web interface. Monzo doesn't have this self-set limit feature.

No web interface. Using a phone for everything is annoying.

Monzo do have very responsive and knowledgable customer service. And a very distinctively coloured card.