Trackers and bank accounts | Hacker News Reader

Trackers and bank accounts

windytan.com

301 pointsdezgeg47 comments

This "just SHA1 it" approach to data anonymization is getting really old.

Previous: http://dataabinitio.com/?p=442

Windytan is one of the coolest hackers I've ever met.

i came to say the same thing. her ccc talks are actually worth watching, was really fun to watch her play around with radio.

https://media.ccc.de/browse/congress/2013/30C3_-_5588_-_en_-...

This is great fun. Very accessible.

I agree; Oona is a modern genius when it comes to signal processing.

Your username is strangely creepy in this context.

"In the case of the taxi data, one way to improve on the hashing would be to substitute a random number for each license ID, then hash the random numbers. Not only does this make the hashed values harder to re-identify (because the input has no consistent format), but even if the data are re-identified, the random values are not personally identifiable."

What is the point of re-hashing the random numbers? Once you have replaced the actual values with random numbers I don't know what you get from then hashing those.

Interestingly, the same bank rolled out a new website last year, with no notification of it being updated to the customers. Just found myself staring at an unknown site one day.

Note that it is against the Google Analytics terms of service to record personally identifying data. So even if someone wanted to do this, reporting it to Google would get their GA account suspended.

This is probably actionable. As in lawsuit. But, that's probably too American of me to bring up. Regardless, this really sucks. Thank you for pointing it out and bringing attention to it.

I'm not sure if censoring "google" out of the tag is even worth it, considering how recognizable that url is :)

Awesome. In the US, just discovering that script would probably get you a visit from Federal marshals, much less reverse-engineering the hash to discover your own account number.

I don't think so. This isn't like the AT&T case involving manipulation of a URLs query paramaters to discover other users details.

This is just analysis of data describing the current user (you) that your browser is already sending to a remote site. No manipulation of the traffic takes place. As I understand it, there is (can be) no law against using view-source: or the browser debug tools to see what other URLs are accessed when a page loads.

Would it have worked if it just provided a sessionID to each request that could be matched on the backend to account number and such for their analytics?

They could also have used a real encryption method like AES.

Not useful for tracking unless used in ECB mode, and if they're encrypting anything larger than 120 bits (AES block size) then AES in ECB mode would itself leak information about the encrypted information.

The real thing to do if they wanted pseudonymous values (none of this is anonymous in any way) is either just associate a fresh random value with every account, or if you don't want to have to store any additional information, HMAC the account number with a reasonably long secret key.

It's sad to see so many applications use SHA1/SHA256 when they really need to be using HMAC-SHA1/HMAC-SHA256.

Why would they care that someone tempers with the analytics if it is meant to be anonymous

I assume they want the pseudonymous values, since they probably want to do analytics on the backend. Thanks for the reply about HMAC. I've got some new learning to look into tonight. :)

> HMAC the account number with a reasonably long secret key

By "reasonably long" you mean "of the correct length"? That is to say, equal to the block size of the underlying hash (e.g. 64 bytes for HMAC-SHA256). Any longer that that does not increase strength. Shorter keys will be zero-padded out to the block size and are therefore weaker.

Even just using {b,s}crypt and a larger salt, even without regenning on every request, would be massively more difficult in terms of memory and CPU to reverse.

I am reminded of Scheiner's adage that we live in an age of data pollution, like Victorian smogs and it takes real pea-soupers like this to make us think there might be better ways.

I mean - that is dumb by anyone's standards.

Fun hack, but - yet another stupid large bank/corporation, probably underpaying their devs and not reviewing code ever. Any other ideas on why this happens so often?

People who don't know much about programming, let alone computer security, doing the hiring. They can't write an attractive job description. They probably don't offer enough money. And, they probably are unable to identify the good candidates reliably even if they do show up. This is a cost centre for the business, not a revenue centre, so it probably will never get the attention it deserves.

Seems funny though that the goal of "keeping money protected" is something that the banks want to drag their heels about since they might have to pay for it... On the other hand, "you get what you pay for" seems to apply when they are shopping around for the cheapest devs they can find.

Wouldn't shoring up holes in security ultimately reduce costs though - safes cost money but banks still recognise the benefit of putting them in, and they don't just buy the cheapest one available.

I don't think this simplistic "it's a cost centre" gets to the heart of why banks are seemingly so bad at online security.

If Finland is anything like Denmark, not enough money is probably not the issue. Bank IT is a pretty well-paid job here, near the top of the scale for programmers. But nonetheless has a reputation for being poorly run and just somewhat boring, with a workplace dominated by "suits". In fact you might have to actually wear a suit to work yourself. So it attracts people who want a stable job with no overtime and a large paycheck, and are willing to put up with high management overhead and banking-sector culture.

On top of the issues goodcanadian describes, people often either don't talk to or don't listen to infosec professionals. Not long ago, I saw a job posting for an infosec person who "Knows how to solve problems without saying no".

Security is hard. Hard enough that a lot of people prefer to ignore it.

Please note that an IBAN is not enough to set up direct debit. So giving out users' bank accounts it's not as bad as it would be using ACH.

In a bad case the IBAN may tell you the branch they are at and roughly when they opened their account. Direct debit is a US thing, mostly.

You're talking nonsense:

http://en.wikipedia.org/wiki/Direct_debit

Even scanning that page there's a lot of major economies that work on DDs.

I was discussing usage, not theoretical existence for some subset of cases. Direct debit is rare in Australia/New Zealand (most people prefer to perform transactions themselves on a one-off basis), I've never seen it in Asia in 15 years, and according to my US bank the American implementation is often fundamentally broken and based on some kind of print-and-mail-a-check system, though widely used.

> Direct debit is rare in Australia/New Zealand (most people prefer to perform transactions themselves on a one-off basis)

I disagree; I used to work in an ISP billing department and about 50% of our customers used direct debit. Then ~25% on credit card; and 25% via BPay.

Fair enough. Out of interest, used to = how many years ago? I'd wager it's waning.

(Rationale: need for strong country-specific presence to justify increased integration cost vs. credit card only, consumer gets zero points/benefits)

> Fair enough. Out of interest, used to = how many years ago? I'd wager it's waning.

Quite a while: 10 years-ish?

I doubt it's changed towards credit card; most companies have a 3% surcharge for using a CC. I might believe that more people are using BPay. But direct debit is the easiest: no interaction required from customer, and merchants prefer it as you need to do less in the way of credit checks.

Unless you are relying on some non-general meaning of Direct Debit, then as an Australian - No, it's very common, and can used by everyone, everywhere for almost everything that reoccurs, and is reliable.

Our banking system has some rough edges for the average customer, but in terms of day to day usage; Internet banking, ubiquity of EFT, bank interchange, etc, it's quite good.

If only the banks would open up with some APIs. :)

> Direct debit is rare in Australia/New Zealand (most people prefer to perform transactions themselves on a one-off basis)

Some companies offer a discount for direct debit (over credit card or other payment types). From the data I have direct debit is over 50% of transactions and payments (large Australian company). 50% is far from rare and that is excluding credit card payments...

> I've never seen it in Asia in 15 years

Direct debit is very common in Japan and South Korea, although credit cards are also used for recurring payments. My phone bill is paid via direct debit. My parents' utility bill is paid via direct debit. A client of mine collects membership fees via direct debit.

It's ridiculously easy to set up. It's also easy for fraudsters to abuse. But then again, a fraudster would need to register his business with the appropriate authorities in order to start making debits, and many payment processors require additional details such as the account holder's date of birth. So nobody seems to be particularly worried. People here hand out their bank account #'s like they hand out business cards. A lot of small businesses even have their bank account #'s posted online. Heck, even I have my bank account # posted online, to collect donations for an open-source project.

So, direct debit is everywhere, fraud is everywhere as well, but for some reason, Americans seem to be the only ones who freak out when someone else figures out their bank account #.

Interesting. I've never lived in Japan/South Korea, but in mainland China (1.4 billion people) as far as I can tell it doesn't exist. Never seen in Thailand, Laos, Vietnam either. I'd be surprised if it exists in India. Probably does in SG/HK, but who'd live there? :)

(PS. Typical HN this thread .. make a valid comment, get called out on a tangent and voted down to obscurity. At least we're all learning something ;)

One thing a few countries do (at least Denmark, not sure where else) to cut out most instances of direct-debit fraud is requiring that the first debit from a new merchant is approved by the account owner. This might not technically be a direct debit, though, but is the electronic adaptation of the old "giro" system to function mostly through the direct-debit machinery. When a merchant wants to set up a new client's payments, they send a "giro" request, which is basically a bill with some codes. The client could pay this in the old-fashioned way by taking it to a post office and paying it there in cash; the post office then transfers the payment to the merchant. But what most people do nowadays is log into their online banking, enter the giro #, and say they want to pay it with direct debit. That authorizes all subsequent bills in the same series (i.e. for the same product or recurring subscription) to get direct-debited automatically. But merchants can't normally just pull directly without this initial authorization.

In Singapore, direct debit is known as GIRO[1], and practically any large organisation supports or prefers it as a payment option. Companies of all sizes take cheques, fewer take cash or NETS in person. Credit cards and one-off e-banking bill payments are often supported by the larger companies but not always. In fact, my insurance company outright refuses to take credit cards, and tries their very best to push customers onto GIRO. [2]

GIRO authorisation ("Direct Debit Authorisation") until recently was fully paper, often on carbonised forms with manual signature, but some of the banks have started offering electronic authorisation recently.

People here tend to fall into three camps: the cash/NETS (local debit card) folks who queue up at the post office or AXS machines to pay, those who do one-off bill payment on e-banking, and those who use GIRO/credit card. It depends on how comfortable people are with technology and e-banking in particular, as well as how skeptical they are of the billing organisation automatically charging the right amount.

[1] http://www.abs.org.sg/financial_giro.php

[2] http://www.aia.com.sg/en/customer-support/premium-payment-ch...

Another "used here too" comment, it's common enough in the UK that many bank accounts don't consider you to be actively using your current account (and therefore eligible for add-ons or reduced fees) unless you have two direct debits set up.

It's very common in the UK, for everything from gym membership to the rent. At least in my experience during the 4 years I've spent there :)

Weirdly, IBAN numbers do not have an agreed international standard beyond the country code and checksum. I guess Finish IBANs are slightly more amenable to brute forcing than UK - but only by 26 digits.

http://en.m.wikipedia.org/wiki/International_Bank_Account_Nu...

This makes the switch to IBAN very simple - it's just the country code, a checksum and whatever numbers were in use before the switch. Local businesses can still ask for the old numbers and then transform them to IBAN.

People want the banks to have better and more usable netbanking pages. Improving the UX without tracking the users behaviour is pretty hard.

If some lawyers then say that SHA1 is enough, it is enough, the people implementing it might not even be involved in that discussion.

The real problem I see here is that the tracking data is forwarded to Google servers outside of the EU. This might be against EU laws.

They thought they ended the debate with that Twitter post, but they were merely joining it... on the wrong side!

Reply on news.ycombinator.com