
Trackers and bank accounts - dezgeg
http://www.windytan.com/2015/04/trackers-and-bank-accounts.html
======
revelation
This "just SHA1 it" approach to _data anonymization_ is getting really old.

Previous: [http://dataabinitio.com/?p=442](http://dataabinitio.com/?p=442)

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

~~~
rjzzleep
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_-...](https://media.ccc.de/browse/congress/2013/30C3_-_5588_-_en_-
_saal_g_-_201312281600_-_my_journey_into_fm-rds_-_oona_raisanen.html#video)

~~~
twowordbird
This is great fun. Very accessible.

------
drakenot
_" 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.

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

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

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

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

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

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

------
baldeagle
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?

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

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

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

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

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

------
archimedespi
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?

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

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

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

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

~~~
mattmanser
You're talking nonsense:

[http://en.wikipedia.org/wiki/Direct_debit](http://en.wikipedia.org/wiki/Direct_debit)

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

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

~~~
kijin
> _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 #.

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

------
lifeisstillgood
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...](http://en.m.wikipedia.org/wiki/International_Bank_Account_Number)

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

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

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

