"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.
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?
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.
> 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.
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. :)
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.
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.
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.
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.
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.
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.
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 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 #.
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.
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 ;)
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. :)
> 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.
> 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...
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.
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.
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.
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.
Previous: http://dataabinitio.com/?p=442