Blog News

SquareUp accepts CHIP cards now – will it be enough to get back on track ?

It seems that Square has seen the light, perhaps sooner than the rest of the US : swiping your card is showing to be more and more to be a security and fraud risk. In 2015, all new cards in the US will contain an EMV chip.

This is the reason why I wrote on this same blog in 2011 that Square wouldn’t be able to work in Europe in it’s current configuration

So a few weeks ago, they introduced a new cardreader that can accept EMV Chip-enabled cards. The EMV page contains some worthwhile statistics about exactly *why* the US is moving to using EMV cards. The numbers are staggering : it seems that the US has 24% of all credit card sales, but 50% of the fraud !

The following are lots of links to articles around the web discussing this new card reader and it’s impact for Square.

Mashable has a short article about this new reader, but if you want the technical in-depth details, go for the Ars Technica article. There you can learn for example that the new card reader is not yet fully chip-and-pin compatible : for now, you can only do a signature using the chip card, as the new guidelines in the US do not require that PIN is enabled.

Forbes has some interesting tidbits as well about Square, that it has lost 100 million in 2013, and has burned through more than half of it’s venture capital. Not good for a young company that needs to grow.

Which makes me think that Square is betting big on this new card reader to climb back out of the red.

If they are very quick (and *if and when* their adapter can also do PIN) they might still be able to grab themselves a slice of the market here in Europe and other parts of the world – there are still people here that would love to use the Square card reader as well. However, more and more competitors are launching themselves here, for example iZettle is already active in several European countries.


Cleaning up user input variables on the web (Python)

Only recently I’ve discovered the power of ‘re’ the python regular expression library. Instead of writing long functions that process text character by character to add or remove stuff, you use re, write and expression in regex that achieves what you want and basta! in a few lines things get done.

For example the following function will remove any html tags (preventing Cross Site Scripting) and escape the rest of whatever the user types in:

# Remove html tags and escape the input
def scrapeclean(text):
----# This matches open and closing tags and what's between them
----x = re.compile(r'<&#91;^<&#93;*?/?>')
----# Replace to nothing using sub and escape what's leftover and return the result all in one line!
----return cgi.escape(x.sub('',text))

Remove the dashes when you copy the code – they were added to show the necessary indentation. And for full disclosure : I took the compile statement from the following site (I’m not a regex expert).

So you can call this function from somewhere in your python code and the result will be ‘scraped clean’ of all tags beginning with < and ending with > plus any ampersands other other special characters get to be ‘escaped’.

YMMV – this is very likely not a complete protection against all the things a hacker can input in your website, but it’s certainly a start.


Local swf file with networking workaround: use Mini-Server (Windows)


Recently  I created a small app to show off in a demo. It’s supposed to live on a webserver, and loads an xml file which contains urllinks using an HTTPService, and then assigns these links to buttons in a tabbed navigator flash component that’s located somewhere in the html page.

For the demo, I created a few dummy html pages that are kept in the same directory and pointed the urls in the xml to use those.

The problem I faced was that I didn’t have a handy webserver to store my release build on when I wanted to demo the app – when I started it up using Windows File Explorer, double clicking the bin-release html file, Flash decided to put it in a mixed sandbox security mode: local-with-network, which means that you forfeit local access to other files. And so my app suddenly couldn’t find it’s xml file anymore. And the purpose of the app is to put it up on a website, the local execute was just to demo to app.

[When you run your app inside the FlexBuilder program, by the way, this all works fine without any problems – it’s only when you do a release build that you suddenly start to learn about security sandboxes and apps with local or networking rights.]

I didn’t fancy writing a server in Python/CherryPy. Although quite possible,  it would take time, and I wanted a solution right then and there. It needed to be portable, and smallish, and as long as it could serve some static pages with client-executed content in it I would be happy.

Enter Mini-Server, which is completely standalone program, vintage 2006, about 462K, and does the job admirably. If you install PHP and show it where it lives it can even do php pages. It’s made by John Owen, which apparently is a nom de plume for a whole rafter of bitmonkeys who churn out one program after another… 🙂

Anyway, the problem is now solved: I start the mini-server, specify the port and root folder (only once, an ini file is saved for the next time), and hit run. I can then show off my demo site with a flash app that is served via http. Once the demo is done, I hit the stop button. It all fits on a usb stick, neat !

Please note that this is a small server for development purposes only. The author notes this as well, and it’s not something  I would stick on the intarnet without extensively testing it’s capabilities/security issues. But it is still a neat program to have on your usb stick when you rapido need a webserver!

Another solution is, on compile-time, using the flex-compiler publish setting to indicate the sandbox you want your application to be in. A user can then trust the flash app and it can then use both local and networking links. See the above Adobe link in the text for more details if you are looking for that solution.


How spammers defeat captchas

Captchas were (and probably still are for the moment) a good way to defeat automated spammers.

They are those deformed letters and numbers that you, as a human, can still recognise and type in, but which a computer program cannot because they do not correspond to the letters they know and the slanting changes randomly. They are used on websites for everything for posting comments to blog to signing up for new accounts.
But now hackers, ever inventive, have found a way around this. In this bbc news article is told that hackers are using human (ahum ‘male’) fascination for nakkid women to a new level. For every layer of clothing that gets removed you need to respond to a captcha. And the thing is, these captchas are dynamically retrieved from other websites, where the response to these captchas is used to post spam comment or using a program to auto-signup for a new account !

Very clever ! We’ll have to find a new way or a new variation on captchas.