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.

That's worse than accidental logging.

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

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.

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

  .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

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.

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.

Principle of least surprise and all that.

    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

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.

    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
    

    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
    

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

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

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.