IC3 Alert on Microchip-Enabled (EMV) Credit Cards

Unfortunately quite accurate and what a number of us have been saying all along:


The gist can be found in a single paragraph:

Although EMV cards will provide greater security than traditional magnetic strip cards, they are still vulnerable to fraud. EMV cards can be counterfeited using stolen card data obtained from the black market. Additionally, the data on the magnetic strip of an EMV card can still be stolen if the PoS terminal is infected with data-capturing malware. Further, the EMV chip will likely not stop stolen or counterfeit credit cards from being used for online or telephone purchases where the card is not physically seen by the merchant and where the EMV chip is not used to transmit transaction data.

You can look at EMV two ways – a good start, or a lot of effort and money, in retrospect, put toward the wrong solution. Yes, it is better than the status quo in the states, but it doesn’t so much as solve the issue as shift it. The fact is, memory scrapers will still be able to get the vast majority of information they need to create counterfeit cards for use in locations or merchants who have yet to embrace EMV, or alternatively, use the cards online where EMV is inapplicable.

Coupled with lack of PIN (we have “Chip and Signature”, not “Chip and PIN”), what we have is something that effectively protects the banks more than the merchants. In fact some argue that it is particularly punitive to small businesses.

While there is no panacea – the hackers will find a way, perhaps a better investment would be driving merchants to P2PE and E2EE solutions (or hybrids). That too would be expensive for merchants to implement, but at least addresses most of the major concerns in today’s security environment.

As always, the opinions above are my own, and do not necessarily represent my employer’s.

UPDATE: The above has hit the media, but seems to have disappeared from the FBI site. The question is – was it “too hot to handle” in the end?

Swift to C++

So having just watched a great webcast from O’Reilly on Swift (and certainly having plenty more to learn):

  • Protocols == Pure Virtuals
  • Generics == Templates
  • Extensions == Class Derivation/Extension/Overloading on steroids
  • Operator Overloading == Operator Overloading, again on steroids.
  • Closures == well, nothing innate, but pretty much same thing as Python Closures

Curiously, and I wonder if it causes problems, that there is no “protected” equivalent. Also from a purely base syntactic level it looks remarkably Scala-like though it falls away quickly on analysis.

Interesting language, definitely. Topic reminds me of Jason Bock’s “If Carpenters Were Hired Like Programmers”.

If you needed one reason…

To watch the “IT Crowd“, this alone would be it:

Get rid of annoying “People Pane” in Outlook

I wouldn’t mind the “People Pane”, except that in our organization is shows nothing useful. Moreover for a reason I cannot fathom, it always gets opened up, taking enormous reading real estate. So from this (Outlook 2010 at least):

Click the “View” tab:

Select “People Pane” and set it to “Off”:



Same two steps work on Outlook 2013.

More on “tiny” URLs…

I keep getting them from very smart, very security conscious people. However, to make my point:


I love what they offer but…

Some do offer a preview, but users aren’t used to seeing that and unfortunately won’t care (ie: they are so used to getting them without preview, they won’t expect it or demand it).


As a coworker pointed out, there are potentially plugins for Firefox etc. (I couldn’t find one that worked) or you can use a site like this:


It’s already come in handy for me a few times.

Python – some truth in this…

I have to say even as a relative newcomer to Python, I find a fair bit of truth in this:


Working in a non-homogenous (that is, heterogeneous OS) environment where Python 2.x vs. Python 3.x is not guaranteed, the lack of backwards (or forwards) compatibility is problematic. If nothing else it erodes trust in the language – will Python 4.x inflict similar pain? Should I be looking to yet another language that isn’t so willing to shoot itself in the foot?

Not all environments, even if they should be, are Puppet-perfect and portability is still a major requirement.

This is to some extent what happens when languages become religion and “purity” to ideological dogma becomes more important than functionality. While I have to praise the desire for perfection, sometimes the perfect really is the enemy of the good.

All that said, as Python becomes more “native” to my mentality, maybe I’ll change my mind. I’ve found the transition to other languages, OSes, etc. offensive to my sensibilities only to later become “assimilated to the Borg” as it were.

Using LDAP Paged Controls with Python

Most LDAP servers can be set to return an unlimited number of entries on an LDAP search, however depending on the size of the LDAP database/directory this can possibly exceed your memory. Moreover if you want to write portable code, you probably should not depend on the LDAP server being able to return unlimited entries. For instance, AD’s LDAP generally defaults to 1,000 entries maximum.

Because using LDAP paging isn’t very difficult there’s not a lot of reason to not use it. Adding paging only marginally reduces performance, while certainly putting less stress on the LDAP server(s). Personally I recommend you use it on a general basis, even where not strictly necessary.

Python’s LDAP supports paging, though it isn’t well documented. I found two examples this one and this one. Both had their pluses, but neither explained what was going on too much. I melded them together, added comments, and streamlined a bit. Hopefully this will help you get the mojo…

As a final note, one of the documents I found said the paged controls did not work with OpenLDAP. That’s not what I found – pretty much the exact code above worked without issue with OpenLDAP.


A GitHub “Gist” for the above can be found here.


For users of Python LDAP 2.4, you should check out of the comment by Ilya Rumyantsev which gives a forward/backward compatible set of code snippets since the API has changed a bit. Many thanks to Ilya for the update.


Below I took Ilya’s updates and merged them in with some minor enhancements to compare the Python LDAP version on the fly. My next stop is to take this and convert it to a generator function, which would be more ideal than using a callback. The issue with going to a generator is handling the errors, which means throwing exceptions in some sane fashion…

How to probe ethernet capabilities…

Mostly for my own edification – use “ethtool”, eg:

You’ll note two important details about this output:

  1. This NIC is gig capable but is only running at 100mbs.
  2. I claim to be running this as root, but any good sysad should be using “sudo” instead!

Anyway, simple command, but sometimes you forget them.

Mmmm… Mmmm…

A little off topic but, when in Philadelphia… Mmmm… Mmmm…

Internation Smokeless BBQ Restaurant and Buffet



Mmmmm… Mmmmm… again!

E MEI Restaurant

Nothing new here…

But everyone should read it:

Password strength. Longer better than complexity.