Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Monzo urges 480k customers to change their pin numbers

theguardian.com

Post reply on HN
Print view View original

31–40 of 66 posts

Re: Monzo urges 480k customers to change their pin numbers

#31

Post by ancarda »

BillinghamJ wrote: post #12
buro9 wrote: post #9

You can read in the announcement the need to update the app, meaning it was the app that logged the PIN and this led to internal logging. I love Monzo, but one thing that does concern me greatly are banking apps (or any apps that touch highly sensitive pieces of information) that include third party components or make any communication to third parties. In the case of Monzo: https://reports.exodus-privacy.eu.org/en/r…

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.

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?

Re: Monzo urges 480k customers to change their pin numbers

#32

Post by lol768 »

BillinghamJ wrote: post #12
buro9 wrote: post #9

You can read in the announcement the need to update the app, meaning it was the app that logged the PIN and this led to internal logging. I love Monzo, but one thing that does concern me greatly are banking apps (or any apps that touch highly sensitive pieces of information) that include third party components or make any communication to third parties. In the case of Monzo: https://reports.exodus-privacy.eu.org/en/r…

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.

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

Re: Monzo urges 480k customers to change their pin numbers

#33

Post by lol768 »

ancarda wrote: post #31
BillinghamJ wrote: post #12

Earlier quoted context omitted.

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.

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.

Re: Monzo urges 480k customers to change their pin numbers

#34

Post by buro9 »

ancarda wrote: post #31
BillinghamJ wrote: post #12

Earlier quoted context omitted.

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.

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?

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.

Re: Monzo urges 480k customers to change their pin numbers

#35

Post by BillinghamJ »

buro9 wrote: post #30
keraf wrote: post #23

Earlier quoted context omitted.

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.

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…

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

Re: Monzo urges 480k customers to change their pin numbers

#36

Post by BillinghamJ »

buro9 wrote: post #34
ancarda wrote: post #31

Earlier quoted context omitted.

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?

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.

Re: Monzo urges 480k customers to change their pin numbers

#37

Post by _0o6v »

pidg wrote: post #20

As someone who is fully drunk on Monzo kool-aid, well done to them on (a) identifying the problem and (b) immediately telling customers what to do. Imagine how long this would have been an issue if it had happened at Barclays or TSB.

I find it bizarre how people aren't giving Monzo more of a hard time over this. This is a security blunder of the highest order. Saying sorry in a cutesy email after the fact doesn't in any way make up for it.

Re: Monzo urges 480k customers to change their pin numbers

#38

Post by benj111 »

this_is_not_you wrote: post #29
benj111 wrote: post #22

Earlier quoted context omitted.

Off topic, but is there a name for names that are diagnostic or demonstrative of the thing. Eg you can't say 'lisp' with a lisp, have trouble spelling dyslexia with dyslexia. 'hippopotomonstrosesquippedaliophobia' is the fear of long words, TLA (three letter acronym) and the above obviously.

I think you are looking for: https://en.wikipedia.org/wiki/Autological_word

Perhaps? The examples given seem much more limited to the qualities of the word itself, I'm not sure the lisp example would fit under that banner.

That page does link to 'Ostensive definition' though:

"An ostensive definition conveys the meaning of a term by pointing out examples"

So perhaps 'Auto-ostensive'?

https://en.m.wikipedia.org/wiki/Ostensive_definition

Re: Monzo urges 480k customers to change their pin numbers

#39

Post by scrollaway »

_0o6v wrote: post #37
pidg wrote: post #20

As someone who is fully drunk on Monzo kool-aid, well done to them on (a) identifying the problem and (b) immediately telling customers what to do. Imagine how long this would have been an issue if it had happened at Barclays or TSB.

I find it bizarre how people aren't giving Monzo more of a hard time over this. This is a security blunder of the highest order. Saying sorry in a cutesy email after the fact doesn't in any way make up for it.

Probably because it's not a "security blunder of the highest order".

Equifax was a "security blunder of the highest order". This is an it-happened-to-Facebook-and-Google "shit, some sensitive info ended up in internal logs" blunder where there's no reason to suspect the PINs actually leaked out of the company. And even if they did, a PIN on its own is not sensitive information - unlike a password, it's just a 4 digit number, there's only 10000 of them. And unlike SSNs, they can be changed. I can tell you my PIN is 1077 and what on earth are you going to do with that information?

Re: Monzo urges 480k customers to change their pin numbers

#40

Post by mcny »

buro9 wrote: post #17
BillinghamJ wrote: post #12

Earlier quoted context omitted.

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?
Post reply on HN