Filler

As I previously mentioned, I like AutoIT a great deal, but I like decompiling other people’s stuff even better. Just a couple days ago, the genius who brought us the only 3.2.6 decompiler released a new version, 2.2. I haven’t kept up like I should, but if cw2k ever gives me the okay, I’d gladly keep up a mirror as he releases new versions. For now, at least, I’ll just try to remember to check back regularly and grab the latest versions.

So if you want my local copy of myAutToExe 2.2, it’s here. If you want to get it from the source, check out either the main forum thread or the actual angelfire site.

Enjoy!

I’m a huge fan of AutoIt - I think the program is a wonderful tool for administrators as well as casual programmers who just like to mess with stuff. However, I recently discovered that the developer of AutoIt, in an ongoing quest for “security,” has disabled the ability to reverse-engineer autoit scripts!

Now, I’m all for security when people write software, but giving scripts this level of security actually introduces security risks! I just don’t like running some random AutoIt script without being able to look at the source code. If I run a “normal” compiled app, my virus scanner will generally let me know if it’s safe to run. But a script written in AutoIt can so easily be a trojan (or other destructive tool) and nothing can likely catch it because of the nature of scripted programs.

Yes, I’m aware somebody could write a C++ app that’s just as dangerous as AutoIt can produce, but this requires a lot more intelligence and effort than just writing an AutoIt script. AutoIt is made to be pretty friendly for non-programmers.

So to me, this is an absurd limitation - all scripts should be reversible for the sake of security! Luckily for the world, somebody has written a usable decompiler called myAutToExe, and I’m providing a local copy of 2.00 Alpha since the site is hard to find and hosted on Angelfire. For the original and latest versions, go to http://defcon5.biz/phpBB3/viewtopic.php?f=5&p=5735.

Note: I haven’t contacted the author of myAutToExe about this (the page has no contact information). I can’t imagine he’d complain, but if anybody knows a way in which I can contact him, I’m all ears. I’d love to set up a proper mirror.

UPDATE: I’ve updated the link to the latest version since being contacted by cw2k (the author of myAutToExe).

UPDATE UPDATE: Fixed the URL for getting the latest version - apparently the forum site moved.

I have been dealing with XSS at my so-called “real job” recently, and it has come to my attention that a lot of people in this world are under the mistaken impression that it’s better to do “input filtering” than “output filtering”. As I pretty much came up with these terms myself (they may or may not exist elsewhere; I’m just too lazy to find out), I’ll define them for you:

Input Filtering: Scrubbing XSS-dangerous data out of your input before it gets saved anywhere.

Output Filtering: Scrubbing XSS-dangerous data only upon display.

Now, the most important concept here is that XSS is most dangerous when a user can see immediate results without alerting you, the web designer. So if you have a page that repeats their parameters back at them (say a search page where you put “Your search for $parameter could not be found”), that’s A) independent of input vs. output scrubbing, and B) extremely by far the most dangerous kind of XSS vulnerability. Why? Because it allows a user to post a link to your site that can execute malicious javascript. Bad, bad, bad.

After echoing user parameters is fixed, you have to look at how you display stored data. This is where the type of scrubbing comes into play - do you scrub the data before storing to your database / file system? Or do you only scrub when you’re about to display the data?

I will soon prove that input scrubbing is for pansies who are paranoid and tend to make up pathetic lies about their imaginary 20-year-old girlfriends.

h2. Why input filtering is inefficient

• It’s bad to store data in a display-specific way (have to unencode when displaying PDF, email/text reports, etc).
• You have to modify other areas of code than just DB storage, such as searching (search for “<blah>” won’t yield “&lt;blah&gt;”), which may not be immediately obvious. ** You could just auto-filter all incoming data, but there may be cases where you really can’t or don’t want to. I personally dislike blind filtering like this unless there is no better option.
• If you have existing data, you have to check it for pre-existing problems. With large data, this can be very slow.
• If you’re truly paranoid (as I am), you still won’t trust the DB data and will need to find a way to have input filtering work nicely with output filtering. This is a whole lot more work than just doing one or the other.
• If you use a good MVC system like Rails, you can actually escape all text fields as they’re read from the database if you want. With a carefully written ActiveRecord plugin to Rails, I’d bet you could have all accessors automatically escape their data if it’s textual. And even provide a method for getting at the unsafe data. ** I still don’t like such blind scrubbing logic, but better to blindly display scrubbed data than to blindly alter data before it hits your database.

h2. Why input filtering can be dangerous

• If you can’t trust your programmers to do proper output filtering, why would you trust them to do proper input filtering? ** Yes, input filtering is liable to be in fewer locations, particularly if you filter all incoming parameters, but it’s still not a silver bullet, and has a lot of long-term risks when mistakes do happen (read on for details).
• Compare to output filtering in terms of the bug factor: ** Bugs will happen. If you truly believe you don’t ever write code with bugs, then by all means ignore this section. I’ll get a good laugh when you tell me about your first big project that went from a two-week estimate to a six-month half-finished-and-then-rewritten-from-scratch project from hell. ** If you mess up an output filter: *** You probably have an issue that’s confined to a single area on your site (the area you messed up). *** You do a quick hotfix, and the site is once again safe. ** If you mess up an input filter: *** Every area of the site that contains the data you missed is at risk. *** You do a quick hotfix to stop anything new from coming in, but existing data is still currently at risk. *** You find and quickly fix the very obvious offending data in the database. *** You wait until the site is slow (or you can take it down) and run through all data entered since you suspect the exploit came into existence, fixing it record by record.
• If future XSS issues arise, you have to retroactively fix your old data again instead of merely fixing your filter. ** New xss vulnerabilities won’t arise, you say? Maybe so, but how many times have we computer folk shot ourselves in the foot with presumptions about the future? (We’ll never need more than 640k memory, nobody will still be using this old software when y2k finally hits, etc) *** Note that XSS attackers have discovered that in some cases, the backtick character (`) will work to do specific JS-oriented attacks. This is not a character that is scrubbed by at least two different html_escape types of functions that I know of. Enjoy retroactive data-fixing? Me too!

h2. Why input filtering can be better (and my incessant arguments to prove that it really can’t)

h4. The most logical argument I was given is that in a large enterprise, control of data output gets pretty tricky. So as far as I’m concerned, large companies are the only place the below issues even have a tiny bit of merit. And even then….

• In a large enterprise, you know that nobody will inadvertantly display unsafe data, because all data is safe. ** Unless of course somebody writes a program that makes changes to the DB. Less likely than a rogue program that merely displays data, I agree, but still a possibility. In an organization that’s big enough to be at risk of multiple apps reading data that wasn’t built by the “proper” people, I’d say there is a definite risk that apps will be writing to said data as well. *** At my job, there have been several cases where somebody who wasn’t even a part of IT (a manager and a content designer) modified data directly in SQL, bypassing any hope of safeguards. ** In a large enterprise, I think it’s even more important than ever that all access to the DB goes through knowledgeable IT staff. Yes, I know this is a pipe dream, but I still think proper procedures can allow output filtering to be the clearly correct option.
• You can detect problems with input filters more easily, because you have the data that could be dangerous right at your fingertips. If need be, write a program that periodically audits your data to check for unsafe characters. If you messed up an input filter, this program can save you. ** Good testing does this same thing for output filtering. It’s far harder to write perfect tests for your app’s HTML output than to write a program to audit the DB for unsafe data, but it’s still the right way to do it. ** Resource usage is wasteful in my opinion, when the resources are being used to prevent data from simply being stored in its original state. ** If you have a large amount of data that is changing all the time, this solution may simply not be doable. In what situation would you have that much data changing that regularly? Oh… I don’t know… maybe in a big corporate enterpise?

I belong to a forum for game developers (”http://www.pbbgdev.com”:http://www.pbbgdev.com) and I recently posted about how to keep one’s game from being a target of the most common security problems. The information seems, to me, to be so obvious, but apparently there’s a lot of ignorance about how to secure an application as well as why it matters. So let me relate a tale of exactly why website security is so damned important.

I relate the details of this hackery not only to brag (I am proud to have hacked this game so thoroughly even if it wasn’t much of a challenge), but also to point out how “minor” security issues can destroy a game (or other web application) completely. This is not a “Security on the Web 101″ as much as proof that bad security can destroy a good concept.

A long time ago, in a land far far away, there lived a game designer. We’ll call him “Alphonso”. Because that’s his name. Makes things simplest that way, really….

Alphonso had a grand idea for a mobster-oriented PBBG(Persistent Browser-Based Game). His idea was pretty decent overall, and he opened up the short-lived site Mobster World. Don’t bother looking for the site, it died a long time ago. And this story will tell you why.

In this game, Alphonso had built a few key areas that I’m going to cover: * Logging in * Jobs * Buying Items * Shooting a player * Reading “private” messages * Sending messages

h3. BUT FIRST…

The basic information in here is this: do not trust user-supplied information! You can build an HTML page with all kinds of hidden form fields and use cookies and all that stuff, but at the end of the day, if you assume that the user will supply you with a valid URL, valid cookies, and valid form fields, you will get a hacker eventually.

h3. Logging in

This was the most absurd area. You’d put in your name, password, and the CAPTCHA image to prove you weren’t a bot. The security image was a collection of three digits. The images were shown to you on the form and you’d enter the digits in the appropriate field. Fine and dandy up to this point. Problem was, the images were shown separately (CAPTCHAs usually show a single image that contains all the numbers/letters) and this allows an attacker to analyze the filenames of each image to figure out which corresponds to a given number. But worse, the filenames were #.jpg. That is, the image representing “1″ was “1.jpg”. So I could look at the form and see the <image> tags to know exactly what I needed to type - very easy for a bot to do, by the way.

When I thought the login couldn’t get any worse, I noticed a “hidden” field. In HTML, a hidden field doesn’t mean the user cannot see it! It merely means the field isn’t immediately visible! This particular hidden field contained the exact security string Alphonso was expecting. So my bot was very quickly able to grab the expected CAPTCHA string and supply it. The CAPTCHA succeeded in stopping only the most inexperienced of hackers, and those ones weren’t likely to know how to script a bot properly anyway.

Also please note that having a CAPTCHA may indeed stop bots (though rumor has it good anti-CAPTCHA technology is more accurate than most users), but it may also annoy regular users, especially those with minor-or-worse visual problems. If you insist on a CAPTCHA, at least make it accessible to all users.

h3. Jobs

There were two kinds of jobs, where a player could perform a job to gain stats and/or money. The “big jobs” were dangerous (rob a bank, steal a car, etc), and could land you in jail if you failed. The “small jobs” weren’t dangerous - things like petty theft, bar fights, etc. They didn’t have the same rewards, and therefore I didn’t bother to try hacking them.

Each job would give you two or three options for how to perform the job, usually a situation where you could choose to be stealthy or direct or whatever (Robbing a bank via the front door or back door, and other totally unimportant crap). But when the page was created, the actions were pre-determined. The html would have hidden form fields saying whether a given button was going to be successful. This meant when I chose to rob a bank, the “front door” option would already be set up via hidden fields to succeed or fail. So one could very easily submit the form with any button they wanted so long as they set the value of that hidden field to “1″ instead of “0″. Since big jobs were so risky, success yielded pretty good cash. 100% success meant tons of money and no time wasted waiting for your jailtime to end.

Moral: Don’t set up future actions in hidden fields! It’s stupid and very easy to hack! All Alphonso needed to do was do the random check after the form was submitted and this issue would not have existed.

h3. Buying Items

But why bother getting a bunch of cash? What a waste of time! Because the game was so poorly scripted so far, I decided to look at buying items, and sure enough I was confronted with awesome hidden fields. The hidden fields would tell the game that a certain button would buy item X at price Y. Hack the form via a bot, and you could buy any item for $0. This meant the most powerful gun for $0. All the ammo you wanted for $0. Bodyguards for $0 a piece. Bulletproof vests? $0. Medical kits: special limited time offer, two for $0!

So you buy great items for free and you realize you don’t need money.

This is a clear case of relying too heavily on the form to determine what’s going to happen. Instead of having the form store the cost of things, it should be stored somewhere on the server - database, bdb file, whatever. User buys an item, sends that item’s ID to the server, and the server pulls the price from the only source it can trust: itself.

h3. Shooting a player

Mobster World was written to stress uneasy alliances. People start shooting each other and the game degrades into total chaos if some of the mob families (essentially in-game alliances) don’t force order by disciplining their members. Because of this, shooting a player was usually not a good idea without a good-sized family behind you. Unless, of course, you could cheat.

The “shoot a player” area was also plagued with hidden fields. By setting the %-to-hit field to 100, all shots would hit. The best gun only hit 50% of the time, meaning you could fire off a shot and do no damage, but still have all sorts of consequences. And if your target had bodyguards or armor (both were essentially just ways to increase bullet-taking ability), your shot could be totally wasted. So again, shooting was usually limited to a family trying to take down another family. But with a 100% chance to hit, free healing (bodyguards, body armor, medical kits), and free ammo, a cheater could do tremendous damage relatively safely.

The game allowed a shot every 10 minutes, so even a cheater had his limits, but with a single bot I was able to knock an unsuspecting don (leader of an entire mob family) down to 6 bodyguards (from 12) in a matter of about two hours. A smarter cheater could have run multiple bots and destroyed an entire in-game alliance in an hour or less.

This is exactly the same as above - there was no need for the form to ever know the chance of a successful shot. Calculate that on the server and only on the server. Yeah, you might want to display it to the user, but don’t let the user be the one who tells you anything other than the weapon they’re using (and of course validate that they own the given weapon and have ammo for it) and the player they’re trying to shoot.

h3. Reading “private” messages

This is where we move from forms to URLs. Reading a message would require a hit to a page like “/messages.php?id=xxx”, where xxx is the id of the email. Well, because Alphonso didn’t think users could modify the URL themselves, you could put in any id you wanted, and then read anybody’s email. Using this passive cheat, you could see what your enemies planned. Following up with a similar method on the message deletion URL, you could see your enemies’ plans but keep them from letting each other know! I was able to discover that my “enemies” thought I was an ex-player they had pissed off a while before I started playing. I catered to this fear and made up all kinds of interesting stories about revenge and such.

Simple fix here - if a user requests access to anything private, make sure they are authorized to see/edit that item!

h3. Sending messages

Once I got bored of looking for “boring” exploits, I decided to check out “XSS”:http://en.wikipedia.org/wiki/Crosssitescripting possibilities. I’m not a security expert, so I only knew how to do something similar to what the wikipedia article calls a “type-2 attack”. And I wasn’t interested in stealing these people’s accounts or anything, I just wanted to mess with their game.

When sending a message, I found that I could embed any HTML I wanted. So with very little effort, I made the private message receipt form appear to have a button on it that looked like the usual “Delete” button, and made the rest of the real page end up hidden so that the only button on the form ended up being mine. When my delete button was clicked, it actually took the user to the “Shoot a player” page, with one of my enemies as the target.

After some testing with a friend, I discovered that I could make a user run literally any action in the game, from failing a big job (giving them jailtime), shooting their own don, going into hiding (forcing them to log out for 8 hours of real time, unable to perform any actions), etc. Had I been evil enough I could have logged out all the players who disliked me except for one, and systematically killed them one at a time.

With a little more tweaking, I found that I could use AJAX to actually make the person perform these actions without even clicking a button. The incoming message could be as simple as “You suck!”, and by merely viewing it, the player committed to the action(s) of my choosing.

It is important to note that many designers think they can get around this issue by stripping out <script> tags - this is not the case. I can embed malicious code in something as simple as a <b> tag just by handling a JavaScript event, such as onMouseOver. Simple solution: do not allow HTML in user-supplied data. For my “big” game (Bloodsport Colosseum), I allow formatting via “Textile markup”:http://en.wikipedia.org/wiki/Textile(markuplanguage). There are many similar solutions for all kinds of scenarios, and they are, in general, far safer than trying to allow HTML in any form, even if you think you’re being careful.

h3. Email to Alphonso

I wrote Alphonso an in-game email asking if he was aware of cheating issues. I figured he’d deny it like so many web app designers who don’t know security. He surprised me:

yes I am aware of it and thank you very much for assisting me in this game: I have other areas that I am repairing first and I will be getting there soon. Please continue to inform me of areas that you find.

At this point I felt pretty bad and told him the truth - I’d been exploiting the game from day 1, and I pointed out all the areas I thought he needed to look into.

Read my response “here”:http://blog.nerdbucket.com/pages/emailtoalphonso_mw if you’re curious how much of a dick I can be when I’ve hacked you black and blue.

h3. Final Word

Do not assume users won’t edit forms and submit bogus data. Do not let a user alter or view anything he doesn’t own (if he says he wants to view message id 10, make sure he is authorized to do so!). Cookies, URLs, and form fields are extremely easy to edit!

There is also the unmentioned SQL Injection attack. I can’t help much with these as I know very little about the attack, but “this wikipedia article”:http://en.wikipedia.org/wiki/Sql_injection will give you a great deal of help. The most important thing here is that most database drivers have built-in features for keeping things at least moderately safe. USE THEM!

Web security is much more important than most programmers seem to realize. If you want a game or other app to get popular and last a long time, do not skimp on security. Or you, too, could end up with a good idea that does as well as Mobster World.

“Digg it”:http://www.digg.com/security/WebsecurityandMobsterWorldataleofwoe!

“PCI compliance”:http://en.wikipedia.org/wiki/PCI_DSS is a good idea. In theory. At my job we’re adopting all these standards to make all our users’ experiences better, which is really a great thing. But just like every other “good idea in theory”, this one is being abused in horribly stupid ways.

As a professional web programmer who actually cares about keeping my job, I do spend the time to learn little tidbits about security from time to time. And on our team, we have a pretty effective security specialist who makes sure things like “XSS”:http://en.wikipedia.org/wiki/Crosssitescripting and “SQL Injection”:http://en.wikipedia.org/wiki/SQL_injection aren’t going to bring down our rather important e-commerce sites. I’m not even half as knowledgeable as this guy, but I still consider myself a proficient web security person. So to me, being treated like I don’t even know the definition of “security” can be a bit frustrating.

Recently we had a required meeting for PCI compliance. It was not something anybody could get out of, not even our security specialist who regularly attends security conferences. Okay, right, people need to know about security issues. Fine, we’ll all go to Security 101 and be able to have a quick laugh, right?

Yeah, more like a long and somehow excruciatingly-painful laugh. We learned the following things, no joke: * Do not store passwords on a piece of paper under your desk. * Do not hold the locked doors open for people who clearly don’t belong in the building. * If you lose a laptop that contains customer data, such as credit card numbers, report it to a manager. (I don’t know what the other options for this situation could even BE… pretend you still have said laptop by building one out of cardboard boxes?) * If you see a total stranger sitting at somebody’s desk whom you know is not that total stranger, you should report it.

There were other points to learn. Something about “report any anomaly that isn’t normally there” (isn’t that kind of the definition of anomaly?), though that’s not stupid advice as much as a funny way to word the stupid advice.

Then there’s the “don’t ask don’t tell” security policies. One of the speakers talked about how he had to fire a guy who was using some cracking software to test the strength of user passwords. Because, you know, he was using EVIL HACKER SOFTWARE, by golly! The speaker actually said, “He was using software to test the strength of passwords, and while he claimed it was a security test, that’s something hackers do.” Don’t get me wrong, maybe the dude was a malicious hacker (yes, not all “hackers” are malicious), but I’d have liked to hear why our illustrious consultant friend was so sure of this guy’s evil-doing ways…. I had a recent experience that was similar, so the subject is a bit of a sore spot. There was no firing, but I was “talked to” by an exec for having tested and then written up a report to my managers when I discovered some security problems. I guess I made the mistake of actually verifying that my hunch was correct - verification required me to H4X0R other people’s accounts (with their consent, mind you).

Back on topic… so not only was this class totally below everybody in my department, but the only lesson I learned was that you never, ever, point out security flaws that look too technical in nature, otherwise you’re a suspected hacker. Awesome message, PCI consultants! I salute you!

I guess what I’m saying here is that PCI compliance is a great thing when it comes to the big picture - store credit card data safely, don’t store the CVC data at all (the little 3-5 digit number on the back of your card), never send unencrypted customer data anywhere, etc. But once you bring consultants into the mix, every good idea turns to shit.

I’m starting to think that lawyers spawned technology consultants….

On the heels of my amazing discovery of the “PC Mesh Hide Files and Folders“:http://blog.nerdbucket.com/articles/2007/01/15/revolutionary-new-software software, I make yet another Awesome Software Discovery: “jcap”:http://www.archreality.com/jcap/!

CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart) technology is always trying to keep ahead of spam / bot technology. This is just another techno-arms race that will probably never end. But this company, “Arch Reality”:http://www.archreality.com, has devised a “clever” image-based CAPTCHA that is 100% javascript.

This Awesome Software Discovery is “special” because it may be the only CAPTCHA system that is run in the client’s browser exclusively. In most cases, you have to have server scripting (PHP, Ruby, Perl, ASP, etc) to process CAPTCHA information, which is a bit of a pain. You have to maintain state information to know that user X was shown picture Y and such. But with this system, All you need is a client running javascript! How awesome is that? Super easy to set up, even for a web novice.

Spammers, beware! As long as we have people like Arch Reality working on our side, your days are numbered!

…or are they?

Well, this is one of those theoretically sound ideas. Much like Communism and pyramid schemes. Any web programmer will notice very quickly that this is total BS. How do spammers operate? Do they single-handedly man a thousand computers simultaneously, working feverishly to send out their spam? NO. They automate everything they can. And let me tell you, when you automate something like a web-based form submission, the last thing you want to bother with is figuring out some javascript! So what do the spammers do? They fracking ignore it! Which leads us to a CAPTCHA that actually verifies that people who have a javascript-enabled browser are, in fact, real people. WOW.

This one blows my mind. PC Mesh has a pretty crappy concept, but these folks really take the cake! Arch Reality’s only saving grace is the disclaimer that came over a year after jcap’s release:

***NOTICE (01.10.2006): The developer assumes no liability with this resource and it is provided as is. This script is referred to as a “security development” because it can provide some minimal level of security. While it does seem to be an effective elementary form of security the developer does not claim that it is an impenetrable solution and thus the developer does not recommend implementing it for the protection of highly sensitive data.

And to me, even that disclaimer is full of crap. Their product will provide literally no security. If you want proof, hit their “demo page”:http://www.archreality.com/jcap/captcha.html, then disable javascript, then type ANYTHING YOU WANT, and click Submit.

Just like a JavaScript-ignoring bot, you too can break through this so-called security development with ease! I’d like to know where they got the idea that this garbage would be “effective” at anything other than pissing off clients! Almost makes me think Arch Reality is working for the spammers….

I’ve done a small amount of digging, and sadly there are people out there who use this product, and think it provides some measure of security. This kind of ignorance is so easily avoided if the people who write software would spend the half hour to research the actual problem they’re trying to solve.

If I can reach just one person, and that person keeps from hiring these horribly untalented hacks, I’ll feel this blog post was more than worthwhile.

There is a company out on the fringes of technology. Making software that most of us only dream of being able to write. Scoffing at the current obsolete methodologies and practices, these brave new developers have recently pioneered an awesome new era in software development.

This software company is clearly just another one of your typical geniuses not recognized in their time, as the very unscrupulous “CNet / Downloads.com”:http://www.download.com/PC-Mesh/3260-20_4-6263078.html reviews have been far too harsh on this enterprising company.

“PC Mesh”:http://www.pcmesh.com is, of course, the company to which I refer. It is with the most sincere amazement I discovered this little gem of a company today. Or more specifically, the discovery was their “Hide Files and Folders”:http://www.pcmesh.com/hide-files-folders.htm software.

How can I make these claims about this company? Well, for starters, their web site tells us all we need to know: PCMesh Hide Files and Folders is a revolutionary new software product…. But I’m not an idiot - I know to do my homework and not take everything at face value, even a statement so indisputable as that one. So how do we know these guys are the real deal? I’ll go through their feature list, item by item, and explain just how brilliant they are. Some of what you’re about to read may be difficult to accept, but keep in mind that true brilliance will often challenge that which we have been taught to believe, and that challenge can sometimes be difficult to accept. Now, on with the -propaganda bashing- product highlights: * Invisible from the operating system, invisible from virus attack and invisible from spying eyes that won’t even know the cloaked files or directories are present. ** Wow. Just… wow. Okay, invisible files are protected from virus attack and spies. Humans won’t know to look for cloaking software, of course, because this concept is totally new and unique, and even now that it’s out, unauthorized people would never dream of doing research to learn of this exciting new software. As for viruses, yeah, they can’t infect what they can’t find. Too bad most people want to hide data files, not fracking executables. And too bad that when you make those files visible, a virus will then see the OS reading the files and infect them. And too bad a smart virus could easily be written to infect this POS program in such a way as to destroy the data as you try and make it visible. But other than that, yeah, this software is amazingly effective. * Encrypted files are still visible on the hard drive. This makes them vulnerable to attack from anyone who is interested enough in the content of the files to spend time trying to decipher them. And with more and more hackers intent on defeating modern encryption algorithms, a need exists for a better type of protection. ** In fact, this may be the only statement that’s partially true. Granted, most encryption today is nearly unbreakable, especially for home computers that don’t house highly-sensitive data, but otherwise this isn’t a “bad” thing to say. Better encryption standards are always a good thing. Questioning the strength of today’s encryption is certainly a worthy goal. Course, I’m not sure where they got the idea that “more and more hackers” are are intent on defeating modern encryption algorithms. Haven’t droves of hackers (and security specialists and general security enthusiasts) always been interested in defeating encryption algorithms? Without those people, we’d all still be using Caeser Shift Ciphers! * In addition to rapidly becoming obsolete, current encryption programs are slow. ** Rapidly becoming obsolete? Gosh, even the encryption algorithms that are considered to be broken are still pretty strong for the average computer user’s needs. And anybody with data so sensitive that it needs unbreakable encryption can probably deal with the fact that they need to update encryption methods every few years. * It takes as long as 10 minutes per 200 MB to encrypt or decrypt a file, while PCMesh Hide Files and Folders executes instantly regardless of the file size or number of files/folders being protected. Just one click is all it takes to render any file or directory invisible. ** Okay, I don’t know much about encryption speeds. I have to be honest, this could be completely true for a really awesome encryption algorithm. So let’s say they have two semi-true statements. Let’s note here that this software “executes instantly”, which means to me it flags files in some way (prefixing them with $sys$, perhaps?), and doesn’t do any kind of encryption. * Data that’s protected by PCMesh Hide Files and Folders is not visible, so it can’t be attacked. In fact, the software itself does not even run continually, so it does not announce its presence to snoopers and hackers. The only time the software is active is when it’s being used to hide or reveal protected files or directories. ** This statement (or series of statements) is so ridiculous I am amazed. “Security through obscurity”:http://en.wikipedia.org/wiki/Securitythroughobscurity is just plain stupid. If an attacker simply finds out about this garbage software, they’ll know to attack the “invisible” files. And since the files are still on the system, there is no way to truly make them hidden - if this software can get to them, so can an attacker. Worse, the authors actually believed that an attacker will need something continually running in order to realize what’s going on. I imagine PCMesh is populated by people who’ve never even read a single article on security, encryption, or hacking. If hackers had no access to the internet and didn’t know how to research new “protection” schemes, they really wouldn’t ever be a threat. * Better Than Encryption ** Though this is higher on the page than the last few items (its their header in fact), I thought I’d mention it here just after the security bit, to point out how absurd the claim is. Obscurity is /never/ better than encryption for sensitive files. It’s only better than encryption when it comes to files you don’t need strong protection on, and situations where you just want to keep the honest people honest. Nobody can currently break AES, but just spending some time hacking through this product’s disassembly (after unpacking their undoubtedly “proprietary” packed executable) would probably reveal how to find the “hidden” files. Though I suspect it’ll turn out to be similar to the “Sony rootkit”:http://en.wikipedia.org/wiki/2005SonyBMGCDcopyprotectionscandal BS from 2005. * Hide files or folders of any size instantly. There is no processing time. ** Most of the bullet point “highlights” are just repetitive crap from the “Better Than Encryption” section of this website. But this one struck me as funny. It’s really no big deal; it’s just that with computers (and pretty much anything), there’s no such thing as “no processing time”. I dunno, I’m picky, shut up.

So clearly this product kicks ASS. Go out and buy it today.

h3. This is new to me, but I imagine true security fiends have already thought about this issue plenty, so I apologize if I’m repeating “news” that’s already been mentioned.

I came across an interesting security mechanism in my quest to automate some “Kingdom of Loathing”:http://www.kingdomofloathing.com stuff in ruby the other day. Their login system isn’t hosted on a “secure” server, which means that (under normal circumstances) anybody can snoop the network traffic, get your password, and end up stealing your account.

For a web-based game, this isn’t (usually) a big enough reward for the time spent sniffing through network traffic and hacking the account, so most such games haven’t got any security on their login forms (including my web-based games, though I may change this when I’m hugely successful). For online banking, obviously the rewards are much higher, so those sites need to be secure.

But what is it to be a secure web site? At the time of this writing, I’m of the belief that it costs a good deal of money to have essentially public-domain technology applied to a web site in order to get the stupid little “this site is secure” icon that makes people willing to put credit card, social security, and other private data into a web form.

I’m not saying that “VeriSign”:http://www.verisign.com is just in the business to rip people off - they provide a lot of services other than just encryption. My problem is merely that the technology of encrypting sensitive data, and assuring a user that a site is safe, shouldn’t cost an arm and a leg, especially for low-traffic sites such as a niche web game, where annual profit may be as low as one or two thousand dollars.

The technology used for website security is pretty basic, really. I mean, it’s powerful stuff and considered unbreakable, but the same security is available in libraries for dozens of languages for free - it’s just strange to me that these algorithms cost so much money ($500+ per year) to implement on a web server. Which brings us back to “Kingdom of Loathing”:http://www.kingdomofloathing.com….

I was writing a little script to automate login, trading, and some other minor things in this game. When I reached the login I found a very interesting twist - when you submit the form, your password is not sent to their servers. Instead, your password is processed and altered quite a bit: * The server sends your browser a session-specific “challenge” code, which is essentially a one-time code for encryption (yes, I tried using the same code multiple times with no luck, which makes me think it’s probably stored on the server with your session data). * Your browser uses javascript to first get an MD5 of your password, then an MD5 of that value concatenated with the challenge code. * This final MD5 is what’s sent to the servers.

This system doesn’t provide what VeriSign provides - it is only encrypting data going from the browser to the web page, not an entire area of the site. Incoming data is totally unprotected, which can be problematic in some cases (although I’d bet clever javascript could fix that to some extent by using true two-way encryption). And let’s face it, simply using a couple MD5 hashes and one-time keys isn’t enough to guarantee security. I’d imagine if the reward was high enough, somebody could figure a way to capture the data for a while, analyze it, and eventually work out either a password or else a security hole of some kind.

But it isn’t so much about having 100% security in this case - it’s about having “good enough” security for the situation. If the rewards aren’t worth the time, even a simple “Caesar cipher”:http://en.wikipedia.org/wiki/Caesarcipher is good enough security. And if we could implement a decent key exchange for a more powerful encryption system (”Diffie-Hellman”:http://en.wikipedia.org/wiki/Diffiehellman plus “AES / Rijndael”:http://en.wikipedia.org/wiki/AdvancedEncryptionStandard, for instance), we could ensure that small pieces of a site were 100% secure “for free”. From my minimal research, it does appear that many encryption algorithms do already exist in javascript.

So for all the web game developers out there, or other small-profile sites - if the only security you truly need is a few form passwords here and there, this MD5 solution used by KoL is probably not a bad fit. And if you need more security, a fully javascript solution shouldn’t be discounted, especially if you need high (but not necessarily perfect) security, but don’t have the extra money to pay for it.