Taking candy from a baby
Maybe they wouldn't have had such a glaring vulnerability if they submitted themselves to the same PCI compliance extortion they inflict on my small vendor clients
Hackers who stole bank account details for 200,000 Citigroup customers infiltrated the company's system by exploiting a garden-variety security hole in the company's website for credit card users, according to a report citing an unnamed security investigator. The New York Times reported that the technique allowed the hackers to …
Yes, and conversely you can have a secure setup that doesn't meet PCI complicance rules, which I think is what pj3090 was getting at.
There are a number of things that are taken as gospel requirements by PCI vetting people with no real knowledge of why or if they are in fact such a good idea. Such gems as blocking all ICMP packets (every wonder why PMTUD doesn't work?), NAT=secure (no it doesn't) - the list is endless.
When a pointy haired management type decides to go for the lowest cost consultant or the off shore resource (uhm they call it global sourcing these days...) One has to wonder if they calculated the costs and loss of good will when someone doesn't do their jobs and secure the site?
Just a curious question about expectations of top notch software from sub par developers. Doesn't that mean that the management chain is also sub par?
“Think of it as a mansion with a high-tech security system – that the front door wasn't locked tight,”
Given that a valid login session was required, I think it might be better described as given a new resident the keys to their house, which happens to fit every other lock in the city if they care to go and try!
However you describe it, it's a pitifully bad way of securing any website, let alone a financial one!
is in dev, before go-live. A few quid on pen testing now saves a million in fines later. Why is it so difficult to convince people of this simple risk mitigation? I have to say a big thanks to Citi as, thanks to this glaring example, it will now be much easier to make the case for testing.
The problem here is not that the account numbers were unencrypted - after all, account numbers are public knowledge once you write a cheque or do a bank transfer. The problem is that the account details could be requested by an unauthenticated person. This is gobsmackingly, unbelievably stupid.
I don't think you quite understand what is meant by public knowledge.
Public knowledge refers to something that is available to all of the public or easily obtained information that one could obtain publicly.
When you do a transfer or transaction only the parties involved in the transaction know your account numbers. Unencrypted account numbers *is* a problem.
You are correct that the ability of anyone to be able to query the back end database about any other information also a major problem.
Either problem is a critical flaw, and neither would be a violation of the PCI spec.
I remember the same basic mistakes being made repeatedly in UART (and their discrete predecessors) drivers, especially in the handling of multiple interrupts on noisy RS232 lines and XON/XOFF handling.
DecSystem10, RSX-11M, Olivetti's S6000 mini, Unix Sys V.....
It was clear that knowledge about this was kicking around, but the people who wrote the next OS were a set of new college grads without this previous experience.
Seems we have the same lack of knowledge transfer to the people who Really Count today. Quelle surprise.