Steven Murdoch, a University of Cambridge security researcher, publishes work on banking card fraud, anonymity networks, and currency detection in software.
HN commenters link his page on how printers and image software detect banknotes, and his paper on cloning EMV chip cards.
> That smooths your data by aggregating the plots.
I'm confused about what the smoothing is supposed to be doing, since it's changing the X axis. I would have expected it maintain the X axis and simply choose fewer points (and use an averaging algorithm to produce smooth curves).
When aggregating, can one easily insert a "rug" plot (see http://www.cl.cam.ac.uk/~sjm217/projects/graphics/faithful.html) to indicate sample frequency?
The slider, though, has several problems:
- Lacks labels. The slider operates on some unknown scale of values. So I can't use it to zoom in/out to a specific time range, for exampel.
- Once I have found a zoomed subset, the slider does not let me scroll within it. Clicking on the "filled" part of the slider should modify the subset.
- In fact, there's no way to scroll at all.
- There's no single mechanism to zoom out. Zooming out requires two drag operations.
Yes, I'm sure this is just an example, but the main reason to use a chart library is so you don't have write one yourself, which is why I'm asking about these things. I have a specific app in mind that requires time-series charts, but I'm still looking for the right library that gives me the features I need. I looked at Dygraphs (http://dygraphs.com/) but it seems a bit limited.
Some background information.
The fundamental reason why this is a big deal is that in the UK, the repercussions of fraud are skewed towards customers rather than the banks. The relevant legal standard is that customers must exercise "reasonable care" with their PIN if the bank is to bear the cost of fraud. Of course, banks always insist that their systems are secure, and that it was the customer's fault. http://www.timesonline.co.uk/tol/money/consumer_affairs/article6249940.ece
The Cambridge team has been investigating vulnerabilities in the EMV standard underlying Chip and PIN (ubiquitous in the UK) for a long time.
From 2006: http://www.lightbluetouchpaper.org/2006/03/15/chip-and-skim/
If I understand correctly they first started to find serious vulnerabilities in 2009.
Blog post: http://www.lightbluetouchpaper.org/2009/08/25/defending-against-wedge-attacks/
Paper: "Optimised to Fail: Card Readers for Online Banking" http://www.cl.cam.ac.uk/~sd410/papers/optimised_fail.pdf
Media: http://www.youtube.com/watch?v=U1QAnb-wnTs
They escalated that attack in 2010.
http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-is-broken/
Paper: http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf
Media: http://www.youtube.com/watch?v=1pMuV2o4Lrw
Tor hidden services are not bulletproof. Just as a really simple example, you can do network traffic analysis to find network nodes with one-way traffic to hosts without a correlated public service and deduce if a hidden service is nearby.
There are several exploits which have been used in the past to expose Tor hidden services, and several papers on theoretical ways to expose them. Many of these attacks can be used in reverse to expose the origin of a connection to a hidden service.
In the [not so] extreme case, the govt can always issue a National Security Letter to WaPo and scoop up any data it wants directly from the hidden service servers, similar to its Silk Road and Freedom Hosting takedowns.
The FBI TOR Exploit [ http://resources.infosecinstitute.com/fbi-tor-exploit/ ]
Heartbleed used to reveal Tor hidden services [ https://blog.torproject.org/blog/openssl-bug-cve-2014-0160/ ]
Hot or Not: Revealing hidden services by their clock skew [ http://www.cl.cam.ac.uk/~sjm217/papers/ccs06hotornot.pdf ]
Tor Hidden Service Passive De-Cloaking [ http://blog.whitehatsec.com/tor-hidden-service-passive-de-cloaking/ ]
Your bank has not done this for your benefit and it hasn't done it in a way that benefits you. They've done it to pass on (to you) the liability for any fraudulent activity.
From http://www.cl.cam.ac.uk/~sjm217/papers/fc09optimised.pdf:
"We reverse engineered the UK variant of card readers and smart cards and here provide the first public description of the protocol. We found numerous weaknesses that are due to design errors such as reusing authentication tokens, overloading data semantics, and failing to ensure freshness of responses. The overall strategic error was excessive optimisation. There are also policy implications."
"The move from signature to PIN for authorising point-of-sale transactions shifted liability from banks to customers; CAP introduces the same problem for online banking. It may also expose customers to physical harm."
Meanwhile, I switched to a bank that uses SMS as a second factor and only where it's necessary: I don't need to use an inconvenient calculator.
If you know anything about research into Tor then you should be aware of the insecurities of Tor with regards to passive traffic analysis.
Here's just one such paper.
http://www.cl.cam.ac.uk/~sjm217/papers/oakland05torta.pdf
You don't need backdoors in the program to make Tor less anonymous. You work with traffic patterns & other information gleaned from the network. You can also congest the network & find out more information that way.
Tor is useful but you're kidding yourself if you think it protects you from the NSA. And please, shut up about conspiracy theories. Many of these theories have become verified fact, and the rest are up to bayesian judgement. You should brush up on your history starting circa WWII & learn to what extent the intelligence communities go to have an upper hand. Tor is low hanging fruit compared to breaking certain cryptographic primitives.
I reread http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf, and things are indeed similar to what you describe. If I understand things correctly, the difference is that the "and this enables signing function" part isn't there. It is enabled by default, and gets disabled only when PIN check fails. That is 'necessary' because the terminal can skip this step if it wants to do a transaction without PIN check.
A man in the middle can hide the "check this PIN" request that the terminal sends from the chip and send a "PIN is OK" reply to the terminal. That way, the terminal thinks PIN check succeeded, and the chip thinks it is doing a payment without PIN check.