The previous GPGMail (a *long* time ago), allowed both S/MIME and OpenPGP, so this is a bit disappointing. Their bug tracker has that functionality scheduled for (possibly) version 2.1, and I’ll be trying it again at that point.

There are definitely challenges to having S/MIME and OpenPGP running the same mail client. If you (accidentally) try to do both at the same time, you get garbage that most mail clients can’t understand – because each mail client/plugin applies the encryption in a different order, and the recipient’s mail client would have to know that order. Now, if a person only has a PGP key or only has an S/MIME certificate, then it’s not that difficult – the mail client should select the appropriate encryption.

It is very nice to see that GPGMail is being developed actively again.

One trick was to hide the variable in a closure. In JavaScript, every function has its own local scope. If you define a variable within a function block, that variable is distinct from one defined in the global scope. In a way, the variable is hidden from code executed in the global scope, though the function can provide a gatekeeper method to access it. Consider this block of code:

document.cookie = "secret";

var Safe = function() {
    var cookie = document.cookie;
    this.get = function(magicWord) {
        if (magicWord === "please") {
            return cookie;
        }
        return null;
    }
}
window.Safe = new Safe();

document.cookie = "";

alert(document.cookie);
alert(Safe.get(""));
alert(Safe.get("please"));

The first alert returns nothing – document.cookie has been set to an empty string. The second alert only returns null, given the if statement in the definition of Safe.get. But with the third alert, the statement return cookie gets executed – and that statement is in the local scope of the function, so it returns the cookie variable defined in that scope, which is “secret”. This is the concept of a closure – the local variable of the function lives on as it was defined in that context.

Initially, this may seem to be a good defense against cross-site scripting, since the power of XSS comes from all a page’s scripts executing in the same scope. But as entries in the challenge demonstrated, a script has many resources for attacking itself. For instance, the challenge included code that checked whether a function requesting the secret variable was a mouse click event initiated by the user. That last bit came from checking the isTrusted property on the event, which should tell you whether the click came from a script or from the user.

But in JavaScript, new objects are created by cloning a model object called a prototype. If you change a particular prototype, any new variety of that object will inherit the changes you made. In this case, changing the isTrusted property of a mouse event’s prototype to always be true meant any spoofed clicks generated automatically by a script would fool the protective code and retrieve the secret value.

With each new bypass, Mario updated the code with new protections to block them. Eventually, he created a Firefox-specific version that essentially rewrote the entire page to get rid of the original Document Object Model and all its loopholes. If you’re interested in reading more about other bypass techniques and the challenge’s implications for client-side filtering, researcher Krzysztof Kotowicz has an excellent write-up that covers more details. But the challenge is also worth studying as a way of understanding more about web scripting and XSS. I certainly learned more about closures and event spoofing by tackling the puzzle, and it helps illustrate the difficulties of trying to protect against code running in the same origin and same scope. We may be moving towards DOM features that provide enough security to block even client-side attacks, but for right now, any untrusted script has myriad ways of overcoming client-side protections.

More likely our readers already know that short passwords are practically useless and have adopted longer passwords of 12-20 characters or more.  Perhaps you’ve read the recent xkcd comic demonstrating that several case-insensitive common words strung together are collectively more secure than conventionally complex 10-12 character passwords.  In a general sense, yes, increasing length increases difficulty so much more quickly than making your password unwieldy.  Some of us at Gemini prefer to use whole sentences as passwords (as long as 30-50 characters) where possible.  Even if case-insensitive, a length of 30+ is so non-trivial that brute force attacks are eons beyond impractical.  However, not all account services permit you to use passwords that long, so to remain secure, you have to rely on high complexity (and maximum length).  If you have many of these types of accounts, it may be easier to use a password manager for those accounts such as LastPass, a tool that saves and encrypts passwords for your use, after prompting for a master password (this can be long and complex and also further bolstered by multi-factor authentication).

Sometimes it can also be difficult to manually devise a truly random complex password for these accounts, and for that there are many password generators, but I personally prefer using Wolfram Alpha because it gives a very thorough summary.  Just enter “password of n characters”, where ‘n‘ is the length you require, and it produces a lengthy report.  One interesting application is that it also spits out a phonetic form of your password in call signs, which can help you memorize the one they gave you or be used as a very long password itself.  Wolfram Alpha also displays the password entropy and total permutations of passwords that length for varying alphanumeric sets, which is rather interesting to see, and you can change password input rules, too.  For instance, if I want to write out an all-lower-case sentence of 30 characters for my password, WA tells me that there are about 10^42 permutations and 185 bits of complexity – far too difficult to brute force.  In case you’ve never seen or done these calculations before, this is a terrific way to gauge how secure your passwords ought to be.  It also gives nice examples of each for you to write down (the text isn’t selectable).  This tool is quite handy and was also recently featured on Lifehacker.

Now, the biggest loss from someone stealing my netbook is in data; the hardware really isn’t all that expensive. My netbook doesn’t just contain personal information; it’s also full of important business data. I can and do perform regular backups to make sure I don’t lose any of the data, but I don’t want anyone else reading what I’ve got, either.

That’s where file encryption comes in. If properly encrypted, my data won’t be accessible even if someone has the hard drive. So, with that in mind, I’m looking at three different utilities for encrypting my drive:

TrueCrypt – TrueCrypt is kind of the grand-daddy of Whole Disk Encryption; it’s currently on release 7. Being free for download, it’s rather popular. It offers a range of features, including the ability to perform whole disk encryption, and the ability to create hidden volumes and hidden operating systems, meaning that even if you’re compelled to divulge passwords, your attacker won’t know about these volumes and thus won’t know to get access to them. In addition, TrueCrypt comes with a pretty impressive set of encryption algorithms, including AES-256.

AxCrypt – Another piece of freeware, AxCrypt doesn’t offer quite as much as TrueCrypt. Unlike TrueCrypt, AxCrypt exists for encrypting files and doesn’t have a whole disk option. Also, it’s limited to AES-128 which is not bad but certainly not as secure as 256. It seems to have a bit more open UI, however, letting users execute scripts on it. It’s also more oriented toward online shares and network storage – so if you want to put encrypted files on online repositories, AxCrypt may be the one for you.

PGP – The third tool I’ve been looking at is Symantec’s PGP. Unlike the other two, PGP costs – roughly 90USD per license. What do you get for $90? Well, it looks like it’s not a bad piece of software. As with TrueCrypt, Whole Disk Encryption is an option. It also has centralized management options, so it seems the best of the three for large-scale implementations. In addition, it has a host of certifications, notably FIPS 140-2 compliance. If you’re in an environment where that’s required, this is likely the way to go. While the online information is not immediately forthcoming on encryption algorithms, FIPS-140-2 compliance means that at minimum it offers AES-128.

For my purposes, I’m likely going to use TrueCrypt. AxCrypt and PGP both have their place. But the most important thing? Implement something. It’s easy to put off such a step, but you never know when your mobile device might be lost or stolen.

1. HttpFox: I’ve blogged about this one in the past; it lists for you every HTTP request made during a given browser session, with details on headers, cookies, parameters, responses, and more. Very handy to monitor traffic when you’re browsing around an app.
2. HackBar: Another one I’ve mentioned before, the HackBar is a swiss-army knife that gives you some space for notes, common commands (such as base64 encoding or MD5 hashes), and perhaps best of all, an easy way to execute manual POST requests.
3. FireBug: Perhaps one of the best-known Firefox plug-ins, FireBug is a powerful tool for inspecting a page’s DOM, debugging scripts, and investigating script variables.
4. Cookies Manager+: As you can guess, this add-on lets you view and edit browser cookies to your heart’s content. Useful in tracking and spoofing session information.
5. Modify Headers: Many web apps use special headers in various ways; this tool lets you set such headers manually when making requests. Spoofing XMLHttpRequest commands is one use case.
6. User Agent Switcher: I’ve seen apps with vulnerabilities that only affected mobile versions of the site. This extension lets you imitate just about any browser, allowing you to test different site interfaces.
7. JavaScript Deobfuscator: This is one add-on I only recently discovered, but I can already tell it will be quite useful. It logs JavaScript functions as they’re compiled or executed by the browser, which is particularly useful in dealing with obfuscated scripts.

This list is by no means exhaustive and is geared towards manual testing, but it certainly provides a solid line-up for anyone looking to experiment with web app security. It also shows how easy it can be to get started tinkering with web apps. While I use Chrome for my everyday browsing, I use my tricked-out Firefox setup when I want to dig deeper. If you’re starting out, try using these add-ons against an educational app, such as WebGoat, Gruyere, or DVWA.

I use Visio to diagram networks and web pages that I’m looking at. The network diagramming is pretty obvious – a lot of people use Visio for network diagrams anyway.

Where the value comes for security folks is in the details you’re willing to add to the diagram – what ports are open on the firewall and what servers do they go to?

Another use for Visio is mapping out web pages. You can map out all of the POST and GET variables and cookies that are submitted for each page.

Again, the more detail you’re willing to put into the diagram, the more useful it will be.

So, what’s wrong with just drawing it out? I mean Visio takes a while to draw even fairly simple diagrams. Most people’s handwriting/drawing skills leave a lot to be desired (unless you trained as an engineer or architect), and many times, you’re working with a group of people and need to share the information. Chicken scratch doesn’t help get the needed information across.

All of Facebook’s new security options have been conveniently grouped together under “Account Settings”.  There are several check boxes here, as well as a list of devices that have recently logged into Facebook with your account.

First, be sure to enable secure browsing via https connection, so as to prevent sidejacking, à la Firesheep.

The next few settings affect what actions Facebook takes when a new device attempts to log in with your account.  You can be notified when this happens via email or SMS, but more importantly, you can have Facebook require two-factor authentication by having a verification code sent to your phone.

Below that, Facebook lists the devices you’ve already approved for this account and also the last few devices that have logged in with your account.  You have the option of signing out of these devices.

These security settings are definitely a step in the right direction for Facebook, but they are still not as robust as Google’s two-factor authentication.  Unlike Google, once a device has cleared the two-factor authentication and becomes a recognized device, Facebook no longer requires a code from your phone when you attempt to log in later.  This choice was likely made for convenience, but it does mean that the second factor is nullified if someone has access to your recognized devices.  Of course, you can avoid this issue by clearing all your cookies between sessions or always opening Facebook in incognito/private browsing mode.

Also unlike Google, Facebook does not yet have a smartphone authenticator application.  This means that you will have to rely solely on SMS for the verification code if you choose to enable two-factor authentication.  If you travel beyond local cell coverage (or do not have an SMS plan outside the country), you may not be able to receive the code and log in on a new device.  Because the Google Authenticator app does not require an Internet connection, it provides a simpler and unconstrained alternative to SMS verification.

However, overall, Facebook is making admirable moves to enhance its users’ account security, and two-factor authentication ought to be adopted by many more high-traffic sites (we’re looking at you, Twitter).

The adapter essentially acts as a proxy between your computer and a USB drive, meaning it needs no software, has no operating system requirement, and works with everything from a flash memory stick to an external hard drive. All communication with the USB device is encrypted on the fly using 256-bit AES via a certified FIPS 140-2 Level 3 crypto module, but the key isn’t stored on the drive: at the front of the hiddn adapter is a smart card slot.

When you insert a smart card, you have to enter the corresponding PIN code to use it. (After three unsuccessful attempts, the card becomes locked until a longer PUK code is given.) The device does not appear as an active USB device in the OS until a card is verified, and becomes “unplugged” when the card is removed. The encryption key (or half of it in split-key mode) stays on the smart card, making an encrypted drive unusable without it.

Setting up and operating the hiddn system is very straightforward. You connect it to your computer with a USB cable, plug a drive into the top USB port, insert your smart card, and then enter your PIN. From there, the experience is no different than using a USB drive normally – there’s not even a difference in speed.

When I first connected an unencrypted drive on a Windows machine, it appeared as an unformatted drive. After formatting, it behaved just as it would when plugged in directly. (A few times I had to reconnect the adapter to get Windows to recognize a new drive if I didn’t “eject” the drive first or tried a bad PIN, but those were minor issues.) Trying to use the drive without the hiddn adapter after it had been encrypted brought up another prompt to format – Windows could tell there was a volume, but it was completely unreadable.

After using the hiddn Crypto Adapter for a short time, I started wondering why no one else had thought of it before – or at least why I’d never heard of it before. It’s a great tool for anyone wanting a no-hassle method to encrypt removable storage. The only potential drawback is pricing; two adapters and two sets of pre-configured smart cards can run almost $900. High Density Devices offers a few different packages of units and cards, ranging from one of each to ten, as well as an enterprise key management system for creating new cards. But while some users may find hiddn too expensive for personal use, its flexibility, ease-of-use, and high security make for a combination that’s hard to beat.

One area where I’m increasingly seeing this nonsense is in the GRC (Governance, Risk, Compliance) space. Vendors are making a push these days to add customers, and they’re apparently willing to do it at any cost. Specifically, they’re aggressively pushing their solution onto customers who don’t have a GRC program. That is, these customers typically will have old, weak policies, and no real formalization to their governance or risk management processes. They may or may not have a compliance management program. In short, they have little or no process, policy, or documentation. The vendors are seizing upon these entities and selling them a pipedream; that buying their tool will magically imbue their organizations with a GRC program by virtue of buying a GRC tool/platform. To say the least, this is a dishonest sales practice.

There is no substitute for doing the base work in establishing a GRC program. If your organization does not have a reasonable base of policies, processes, and documentation, then adding a tool will not make this situation any better. In fact, it’ll probably make things worse. Why is that? Simply put: if you buy a tool first, then you will have to change your organization to match the tool. Taking such an approach is a recipe for disaster, because organizational transformation is itself extremely difficult and costly, and even more so when the changes are arbitrary to match a piece of technology. More importantly, all of the GRC program development work will still need to be done, but in buying a tool you will now hamstring your efforts by limiting your options.

The most important lesson here is this: You do not need a GRC tool/platform in order to have a GRC program. In fact, it’s better that you don’t have a tool at first, since it can unnecessarily limit or hinder your program development efforts. Instead, build a program that makes sense for your organization. Once you have the fundamental components in place, then and only then should you consider a GRC platform. In this scenario, you can then properly define requirements for what you need the tool to do, which will let you make a better selection. You’ll find that this is a far more worthwhile approach, and that you will then be able to demonstrate the value from such an acquisition.

It’s ironic: Apple computers were the predominant home computers when computer virii and malware were invented. And yet, the first malware kit for the MAC OS (or, more accurately, OS X), Weyland-Yutani BOT, was only released earlier this month. For obvious reasons, I’m not about to download it and play around, but preliminary reports indicate that this kit may have caused a significant increase in OS X malware. And supposedly, kits for iPad and Linux are just around the corner.

To be honest, I find the iPad more disturbing. An increased awareness of mobile OSes in the black hat community can only mean more malware for those platforms. Various experts have been predicting widespread malware in mobile devices like phones and tablets for some time now. With the release of Weyland-Yutani BOT, we’re that much closer. The exact development cycle for such kits is hard to pin down, but a spike in mobile device malware is likely in the very near future. If you haven’t already, now would probably be a good time to look at anti-malware for all of your computing devices – Weyland-Yutani BOT is just the beginning.