SafeGuard Disk Encryption for Mac 5.5

8:37:00 PM

Sophos SafeGuard Disk Encryption for Mac offers full-disk encryption (FDE) for the Mac, with protection at boot time from unauthorized access. FDE scrambles the entire contents of a disk drive, rendering it ostensibly unrecoverable without access to the long encryption key used, or a shorter account passphrase that unlocks that key.

FDE makes your data secure when someone gains unauthorized physical access to it while your computer is shut down. If a computer with an FDE-protected drive is booted and running, the data is still susceptible to various forms of extraction using forensic tools, even if there's a password lock enabled in OS X. But when the computer is shut down, it's as close to Fort Knox as one could hope.

With Lion, you have the option to use the built-in FileVault 2 FDE that replaces the directory-only encryption provided in the original FileVault system introduced in OS X 10.3 Panther. FileVault 2 works quite well, is integrated into system accounts and system boot time, and relies on AppleCare support as an optional backstop to help with extreme cases in which an account password fails or is forgotten and a separate emergency recovery key has been lost.

SafeGuard, compatible with Lion in version 5.5, has to scale a mountain to convince users to purchase a feature that's otherwise built into the OS. A third-party encryption tool has to do the job right, but also have features or options that set it apart from FileVault 2. (SafeGuard provides a separate installer for Mac OS X 10.5 and 10.6. If you upgrade from Snow Leopard to Lion, it is vitally important to follow Sophos's instructions. An upcoming SafeGuard 6.0 release will work on 10.5 through 10.7, however, according to Sophos.)

Sophos requires that you create unique accounts, separate from Mac OS X, including at least one administrative account.

SafeGuard doesn't quite get there. There are enough rough edges and confusing bits that don't place it anywhere near the ease with which Apple enables FileVault 2, which make SafeGuard hard to recommend highly. Sophos could sand down the interface and documentation friction, while adding a couple of compelling features. However, SafeGuard is a good choice for anyone who prefers not to rely on Apple for their encryption needs for whatever reason.

Using SafeGuard

Sophos relies on its own user accounts set up as User and Admin categories, which means extra account management instead of using Mac OS X authentication. This is clearly required because at startup time SafeGuard has to rely only on what its own system can manage—it can't access Mac OS X or accounts. We can’t ding the product for that, but it's more complicated than Apple's integrated ability.

You set up at least one Admin account to start encrypting the drive with a single click. There's an option to use Fast Mode, which has no explanation in the program or documentation as to what "fast" means. I had to query the company, which explained that with Fast Mode disabled, disk encryption takes a back seat to whatever the user is doing. In Fast Mode, encryption consumes all available computational power, which might slow down other activities.

Admin accounts can enable and disable encryption on partitions, and create and delete regular users. A User can log in at startup. User accounts can be backed up with a third form of account, Recovery, which are one-time use logins assigned to specific User accounts, and which are meant to help in case you forget or lose the password for a User account.

Sophos could provide a more sensible handholding walkthrough here. It should have the option of an assistant that guides you through creating an Admin user, and gives you the opportunity to create a regular User and one or more Recovery accounts. Instead, I had to stumble through the documentation to figure out the precise relationship.

Any FDE system needs to offer tools to help you when things go awry, as normal disk utilities won't work. Sophos includes options in its program's Users tab in a gear pop-up menu, but they're rather hard to parse there and in longer explanations in the documentation. I sorted it out, but I don't expect that even an advanced user will find the explanation straightforward.

Sophos has three recovery options, but it's really two ways to make bootable media, with a third menu item to export your encryption and authentication data. You can either create a generic bootable image without your login bits (which lets you separately attach your authentication data), or you can create one that's bootable and has the necessary credentials for the specific computer from which the disk was exported.

What Sophos doesn't explain is that you need to take the disk image and create a bootable volume from it. This is trivial in Disk Utility. Drag the disk image into Disk Utility, where it shows up in the bottom of the list at left. Insert some kind of media, such as a USB thumb drive, that you're willing to erase one or more partitions of. Select the disk image icon, and then drag the partition of the drive you're using into the Destination field. Click Restore. This creates an EFI-formatted bootable drive you can select at startup time by holding down the Option key. Would that these instructions (with some screen captures and more detail) were in the manual.

Sophos has its own EFI-based boot process that lets you enter a user or administrator account to start up Mac OS X. Only the keyboard works; mice and trackpads are unavailable.

I tested booting from a recovery image and performing various recovery operations, and they worked just fine. As with the rest of SafeGuard, the actual function is there masked by an unpolished interface. You can decrypt a drive quite simply, too. While logged in as an administrator, click Decrypt.

Limitations

SafeGuard also warns you in the documentation against backing up certain files in Time Machine, but doesn't provide a tool to exclude those automatically. SafeGuard can't encrypt external drives. And it requires the use of the keyboard in its boot manager, which makes it feel a bit more like using a newer PC BIOS than a Mac. Ostensibly, they didn't want to include mouse and trackpad drivers.

SafeGuard makes it simple to encrypt or decrypt an entire drive.

The only compelling reason to choose SafeGuard over FileVault 2 relates to boot-drive partitions. FileVault 2 only works on a Mac OS X's boot volume in which the Lion Recovery partition is installed and working. You cannot use a custom partition scheme, and users have reported all sorts of problems if they've messed with Lion partitions. SafeGuard doesn't have this problem. You can encrypt any number of partitions on the boot drive, and a Lion Recovery partition isn't a requirement.

Internet security

McAfee Internet Security for Mac 2012

8:24:00 PM

Mac OS X users are notably resistant to the ploys of anti-virus, anti-malware, and security-monitoring software offered for our platform. “What—me worry?” could be our motto, as well as, “Not paying for that!” Over the long haul, that attitude has served us well, but the nature and diversity of risks has increased, and is likely to get worse.

McAfee Internet Security tries to address the virus, malware, and Trojan Horse issue directly, but also includes a robust, configurable firewall along with a Firefox plug-in that vets and reports on search result links. Despite my many years without such software installed, I’m strongly tempted to continue to use the package after testing because it’s a multipronged and easy-to-manage extra layer that doesn’t seem to slow my computer down one bit, while providing useful information and the right degree of control to block remote access.

The fundamental problem with a tool that prevents the execution of malicious software has been that the damage is usually done by the rapid spread of such attacks before the protective program has been updated. McAfee, like other anti-virus software makers, is constantly monitoring and testing for new vectors and writing defenses against them, and pushes out responses to discoveries in the wild quite rapidly. The software is set to pull down updates every four hours, too.

Protect yourself

McAfee Internet Security warns you about malware. Even if you click Open, it quarantines MacDefender instead of launching it.

Given that only a handful of Trojans and viruses have appeared in recent years for the Mac, and that they are laughable in their ability for users with any degree of proper caution to avoid, this part of the security suite might seem useless. But I’ll argue it is not.

First, it prevents you from passing on Windows viruses that may be sent as attachments that you then guilelessly hand off to friends, relatives, or colleagues using an unpatched version of Windows. (This is also useful when copying files back and forth between a virtual Windows machine or a Boot Camp volume.) Second, you can recommend this software to those who might not have the instinct to stay away from unknown software or attachments. A relative might appreciate having this software installed to prevent them from making a bad choice due to their lack of computer knowledge—especially if they try to install Trojans masquerading as legitimate files. Third, if someone else uses your computer without the same care you have, you’re protected there, too, against old threats and new ones. True, Apple has built virus defenses into Snow Leopard and Lion that are regularly updated. Consider McAfee a more explicit second line of defense.

I tested McAfee’s virus protection against the very few known Trojan horses and other exploits that have been discovered, such as MacDefender. McAfee refused to let me launch or uncompress the archives containing the malicious files, and put them into a Quarantine area to make it simple to review them in a list and then delete them. I tried sending myself a virus via email, and McAfee prevented that from downloading as well. The software can defang the malicious part of infected files, but all the files I tested were entirely comprised of malware.

The McAfee software has three more active components, however, that can protect you if a Trojan appears before they’ve detected and issued a fix, as well as to help you identify malicious Web sites you should avoid. These components let you review programs before allowing them to launch, use a firewall to prevent intrusions (useful to prevent unintended access to file sharing, even), and a Firefox extension that brands the safety of search engine results.

With Application Protection enabled, whenever a previously unused software program (or one that hasn't been given unlimited permission) launches, you're prompted to choose whether to let the program access the network or not, or prevent its launch entirely.

An Application Protection component, configured via the program’s preferences, monitors software when it launches, and puts itself in the way with a pop-up prompt. You choose whether to launch with or without network access provided to the program, and allow the program to be launched once (just when you approve it) or always thereafter. Or you can deny a launch altogether. You can modify choices for individual programs or background processes later through preferences.

Such controls generally prevent software that you didn’t intentionally install from being able to run and take over your Internet connection. Of course, this can’t protect against exploits that use techniques to gain root access to your Mac, and install software that runs beneath the user interface’s service. Apple has patched many such holes, although there is little evidence that such attacks were made from Web sites or via email.

Firewall and Firefox

The firewall is simpler than many full-featured programs, and I appreciate that. For most people, being able to click a few buttons is better than an ocean of pulldown menus and configurations. I particularly like that you can shut down all incoming or outgoing traffic or both with a couple of clicks without having to disable your network interface. You can create custom rules—only certain kinds of traffic may originate from your computer to specific addresses, or block all but a handful of services from receiving signals from the outside world. You can also define trusted networks.

Firewalls have the benefit of keeping normal services you may have switched on, like VNC-based screen-sharing (a somewhat insecure option in the Screen Sharing service in the Sharing system preferences), from being accessible or crackable when you’re on an open network, such as at a coffeeshop.

If you use Firefox, McAfee’s Site Advisor add-on is a big help in examining search results on Google and other engines. It’s more tightly integrated with Yahoo (where it disables dangerous links entirely), but works just fine with others. When you perform a search, the advisor tags each result with a green, yellow, red, or question mark icon. McAfee constantly spiders Web sites looking for malware and other problems, and rates sites accordingly. A McAfee seal of approval appears on ecommerce sites that the firm separately evaluates.

The Site Adviser plug-in for Firefox adds icons to search results URLs to warn you of sites McAfee has found have might cause you trouble.

It’s a hard sell to tell someone who has had no problems and expects none to pony up hard-earned cash for a product that seems unnecessary. But I find the prophylactic effects of McAfee Internet Security aren’t as interesting as the amount of information and control the software provides over the routine function of your system and network connections.

[Glenn Fleishman was first attacked by computer viruses in the 1980s, but he got better. He is the author of Take Control of Your 802.11n AirPort Network, updated for Lion.]

encryption

How to keep your Mac safe from Web security flaws

9:05:00 PM

How to ensure rogue security certificates don't subvert your encryption

This year there have been numerous reports suggesting that the fundamental security infrastructure of the Web is on shaky ground. In March we heard about a collection of stolen security certificates, and in August the release of more than 500 improperly issued certificates came to light.

\Whenever you connect to a secure Internet site, your computer and the remote server need to exchange a strong encryption key in order to prevent eavesdropping by third parties. It’s a clever jig performed hundreds of billions of times a day among hundreds of millions of programs and servers—but the web of trust that makes it work is in peril like never before.

The good news is that changes are afoot to make connections safer than they’ve ever been. But until browser and operating system makers fix the teetering system, you can take some matters in your own hands to improve your own security. (If you don’t want to know this whole system works, skip the next section and go straight to our advice on how to secure your Mac.)

Trust, but verify

If you’re exchanging information over the Internet, you have to assume all communications could be monitored by criminals, trolls, and governments. How can you start this dance if you can’t be sure you’re asking the right partner to participate? The trick devised not long after Web browsing hit the mainstream in the mid-1990s was known as SSL (Secure Sockets Layer); it’s since been updated, and has a new name, TLS (Transport Layer Security).

SSL/TLS relies on digital certificates that provide the cryptographic information for a server to send a session key safely to a client. The certificate is bound to a given domain name, like google.com, and can’t be used at any other domain. These certificates are issued and countersigned by certificate authorities (CAs), of which hundreds exist worldwide. CAs affix a kind of permanent seal (a digital signature) to a certificate that can be checked against a list of trusted CAs built into all major operating systems, whether desktop or mobile. Some browsers maintain their own, separate lists, too. (Safari consults Mac OS X’s list, while Firefox consults an internal table.)

Mozilla's green bar. Safari displays the same information in green text at the right end of the URL field.

Let’s take a typical scenario. google wants to offer secure Web logins. It signs up with GeoTrust to receive a SSL/TLS certificate that works for any domain that ends in google.com. GeoTrust uses some method of verifying that google’s technical chief or IT department should be allowed to receive such a certificate, typically by sending email to a google.com address noted in the domain’s registration. CAs may also request additional information, such as a fax of a business license or driver’s license. For “Extended Validation” (EV) certificates, businesses have to provide even more documentation about themselves, for which they are rewarded with a “green bar” that shows up in most browsers. (To see this bar in a browser, visit Mozilla’s add-on site.)

When the certificate is issued, signed by the CA,google installs it on its servers that handle secure connections. Google.com retains a private part of the key, never shared with the CA, that allows it to decrypt incoming messages used to set up secure sessions. Whenever someone visits the secure site, the certificate is transmitted. It contains only public information, including a public key that corresponds to google’s private one, as well as a signature from the CA that vouches for it.

A browser receives the document, and confirms using built-in CA information that the certificate was correctly signed, and thus that the public key contained in it is valid. These CA signatures are currently considered unforgeable. The browser and server can now privately exchange a long session key and use that to encrypt all the data during the session.

That all sounds dandy. Checks and balances ensure a closed loop. But the problem lies in a couple areas of trust. First, operating systems believe anything they are told about how a domain name (google.com) translates into the underlying Internet protocol (IP) address (58.2.2.1.1) used to make the actual connection. It’s easy to “poison” DNS on a local network, such as at a coffee shop, or for an entire country, such as Iran. You simply need to position bad information at the choke point between where queries are sent by a computer for the lookup of a domain name, and from where the reply is returned.

A certificate that has a domain name other than the one assigned to a server feeding out a secure connection prompts browsers to provide dire warnings that can’t simply be clicked to ignore.

The SSL/TLS certificates are resistant to this, however. You can poison DNS, but you can’t forge a CA-signed certificate. If you visit a server that your computer has been subverted into believing is google.com, and it provides a certificate for another domain or one that hasn’t been signed, then your browser barfs up a message warning about the mismatch. These warnings typically require serious effort to bypass, as opposed to the usual “horrible security flaw: click OK to continue” sorts of messages.

Since CAs control the issuing of certificates, this shouldn’t be a problem—if we could trust every CA equally. Over 600 parties worldwide act as a CA for at least some combinations of browsers and operating systems; Apple’s products honor nearly 200. Every CA can sign off on any domain, and can delegate authority to lesser parties. A security document created by any of these anointed or delegated CAs will look legitimate to all browsers worldwide.

If a CA is subverted or issues a certificate under duress because a government demands it, and a network (whether cafe or country) has poisoned DNS, the entire transaction looks legitimate to a browser. The machine swears it’s a Gmail server and it has a validly signed Gmail certificate from a trusted CA. Thus, the browser doesn’t squawk.

This is the root of all of those scary news stories about rogue certificates. In the last year, several CAs have been compromised, some potentially by government-sponsored crackers. A major certificate issuer, Comodo, had a breach through an affiliate in March, leading to valid but illegitimate certificates being issued for domains controlled by Google, Skype, Yahoo, and others. In August, the Dutch CA DigiNotar was found to have issued over 500 improper certificates, including one for all google.com domains, without providing proper disclosure nor keeping good records. There are almost certainly more revelations to come.

When a bad certificate is issued, whether an improper one such as the examples above, or one simply created with the wrong details in an administrative error, a CA can issue a revocation that is supposed to block browsers from accepting a certificate as valid. But revocations aren’t typically built into browsers or operating systems. To check whether a certificate remains valid, a browser or other software has to communicate with a CA’s revocation servers to either ask about that particular certificate or download a full list of revoked documents. Those servers may be easily blocked by malicious parties or nations—or simply not provide a response fast enough for the client software’s liking. Browsers and Mac OS X are configured to ignore an inability to check whether a certificate is revoked, rather than to make a stink about not knowing the answer.

Because of this, Apple, Microsoft, Mozilla (Firefox), and other operating system and browser makers released updates both to block specific certificates hijacked from Comodo, and to remove DigiNotar from the CA list entirely for desktop systems.

Secure yourself

So what can you do to prevent your Mac from being the subject of a man-in-the-middle snooping attack? Plenty.

First, turn on revocation checking in Mac OS X and in your browser. This may cause some disappointment on slow networks when a CA’s revocation servers aren’t as responsive as they should be.

For Mac OS X as a whole (including Safari, Google Chrome, Mail, and other programs that use secure connections), you need to use the Keychain Access app, located within the Utilities folder inside your Applications folder. From the Keychain Access menu, select Preferences. Click the Certificates tab. You’ll see options you can set for OCSP and CRL. OCSP allows a brief query about a single certificate, while CRL downloads a full list if a cached one from that CA is out of date. Apple sets these to Best Attempt by default, which means a failure is ignored. Instead, choose Require If Certificate Indicates for both OCSP and CRL. Also choose Require Both from the Priority pop-up menu. (The Require for All Certificates option is available if you hold down the Option key, but that doesn’t guarantee such a server can be found if it’s not specified in the certificate. A certificate may be obtained illegitimately, but the CA that issues it will still include revocation server information.)

The only problem with forcing a check of revoked certificates is that Apple has a flaw in how it validates Mac App Store updates. With the option selected as shown in the figure below, you may be unable to perform updates through the App Store program. To fix that, launch Keychain Access, change the preferences to Best Attempt, update your apps, and then reset to the stricter setting. This is something Apple should clearly fix, since all the components of this situation are under its control.

Set OCSP and CRL to always check if a certificate has revocation server information, and make sure both kinds of revocation services are consulted.

In Firefox, select Firefox -> Preferences, then click the Advanced icon. Click the Validation button. Make sure “Use… OCSP” is checked, and Validate a Certificate If It Specifies an OCSP Server is selected. Also check When an OCSP Server Connection Fails, Treat the Certificate as Invalid. Click OK. In using this setting for some weeks, I’ve found a handful of times I’ve had to reload a webpage to get a proper OCSP response.

Firefox doesn’t allow downloading a list, but checks each certificate for revocation.

Chrome has a separate option (Chrome -> Preferences, click Under the Hood, scroll down to HTTPS/SSL) where you can check or uncheck Check for Server Certificate Revocation. Keep that box checked. It doesn’t appear that you can force Chrome to retrieve a list of revoked items, but the documentation is unclear, and it’s hard to rely on in practice. It relies on Mac OS X for certificate management.

Second, if you use Firefox, you can test out a new approach in validating whether a certificate is correct without relying entirely on certificate authorities. Two projects let you install add-ons that use “notary” servers that constantly retrieve certificates and keep track of the signatures on them to alert you if a certificate doesn’t seem to be correct. The Perspectives Project alerts you if your browser receives a certificate for a site that’s different than one found over the last 30 days. Convergence also relies on notaries, but over time will allow other kinds of integrity checks.

Perspectives tracks certificate signatures over time, and warns you if the one retrieved by your browser is different from those stored over the last 30 days by multiple notary servers.

Third, if you use Chrome, Google has and continues to add additional certificate checks. The current release of Chrome only allows certain CAs to vouch for Gmail’s certificate, and blocks other attempts. Expect more along these lines. (In fact, this Chrome feature is what alerted an Iranian user to an apparent use of a DigiNotar obtained google.com certificate on an Iranian network.)

Removing CAs

So what happens if you read a news report about a compromised CA and want to pluck the CA out of your browser as soon as possible? To change Mac OS X’s settings, and thus affect Safari, Chrome, Mail, and other programs that rely on these values, follow these steps.

You can change the value of any built-in certificate authority to avoid letting it vouch for the integrity of secure connections.

Open the Keychain Access app as before, and click the System Roots item under Keychains at upper left. Select the certificate in question from the list, and select File -> Get Info. Click the expand triangle next to the word Trust near the top. From the When Using This Certificate pop-up menu, choose the item Never Trust. When prompted for a password, enter it, and click Modify Keychain (which you are prompted for just the first time). Then enter the password when prompted and click Change Settings. You’ll see a small red “x” in the certificate’s mini-icon.

There’s one flaw, however: Even if you distrust a root certificate, Safari will ignore this lack of trust if a website presents an EV certificate. That’s illogical, and presumably Apple will fix this bug in the future. The only way to ensure that an improperly issued EV certificate won’t be accepted even when you’ve ostensibly blocked the CA that produced it is to stop using Safari until the bug is fixed.

In Firefox, choose Firefox -> Preferences, click the Advanced icon, and then click the Authorities tab. Scroll through this list to find the CA you want to remove. Select it, and then either click the Edit Trust button or the Delete or Distrust button. Edit Trust lets you retain the certificate, but disallow its use. Delete or Distrust removes all trust from built-in certificate authority information, or removes a manually entered CA. (Some companies and other entities may choose to trust a CA separately from the global chain of trust built into the browser.)

You can remove the trust from any certificate authority in Firefox.

What about your phone? Sadly, you’re out of luck. The greatest disappointment in all this certificate authority nonsense is that both iOS and Android have lagged behind on dropping support for suborned certificates and hacked CAs. (Windows Phone 7 never included DigiNotar on its approved list.)

Future Efforts

You might despair after reading about the scope of this problem, and the complexity in managing some of the fixes yourself. But don’t lose hope. With the exposure of these flaws, companies that sell hundreds of billions of dollars of goods a year over the Internet are aware that they can’t allow trust to seep away. Browser and operating system developers are also moving into higher gear to avoid putting customers into compromised situations.

Built-in notary support. Future browsers could include the kind of checks that Perspectives and Convergence offer. Better, you might be able to choose the notary servers you trust, so that you can place your faith in the security of particular organizations. The Electronic Frontier Foundation, which has conducted certificate research, could offer a notary service, for instance. The more notaries, the better, as it increases heterogeneity, which improves the chances of problems being spotted instantly.

Domain pinning. You may see browsers including more support for domain pinning, which allows only specific CAs to vouch for a given domain. Google built in a fixed pin for Gmail’s certificate into Chrome’s recent releases so that only three CAs are recognized as valid countersigners, and has a setting that lets you pin domains manually. One could see Apple, Microsoft, Mozilla, and others pinning domains that relate to their own businesses, and working with other companies and organizations to support a global pinned directory. This tremendously reduces the risk of rogue or suborned CAs.

Fewer CAs. It’s very likely that fewer and fewer CAs will be given the blind trust currently offered. Fewer CAs lead to a smaller risk profile and less exposure.

DNSSEC/DANE. A complicated effort is underway that will allow websites to put digital signatures for their certificates into secured DNS (Domain Name System) records. DNS is used to connect a domain name to a machine-readable IP address, and a decade-long effort to provide a cryptographic underpinning (to kill DNS poisoning, among other matters) is nearing fruition.

Dynamic CAs. Microsoft chose to use dynamic lists of CAs starting with Microsoft Vista. It’s also found in Windows 7 and Windows Server 2008. Instead of having a fixed list of CAs that an OS update is required to modify, Microsoft only caches CAs temporarily, for seven days, using a secured service it operates. On visiting a secured website, if the CA that signed its certificate isn’t cached, Windows consults Microsoft’s list, downloads the validation, and then affirms the website’s certificate. Microsoft was able to dump DigiNotar right away, while Apple took weeks to push out a security update that took care of the problem.

These fixes could all have been in place earlier. But it’s the same motivation that puts a traffic light at an intersection only after pedestrians are repeatedly hit by cars. Late—but better late than never.

air sharing

How to keep your iPad safe

7:07:00 PM

The iPad is one of the safest computing devices you can use. Its combination of hardware and software security translate to a device that’s probably more secure than your PC or Mac—especially if you take the right steps to secure it.

Because there are currently no known remote attacks against iPads, the biggest security risk is physically losing the device. Thus, the first step is to make sure your tablet’s data is safe in case it’s lost or stolen. For that, I’d suggest a combination of encryption and remote wiping.

Passcodes and encryption

All iPads ship with powerful hardware encryption built-in, but you need to enable it. The simplest way to do that is to set a passcode on your iPad: As soon as you do, your data will be automatically encrypted. To enable a passcode, go to Settings -> General -> Passcode Lock and then enter a four-digit code twice. If you’d like to be extra-safe, you can turn the Simple Passcode option on that same page off; you can then use longer codes. While you’re there, you should also set Require Passcode for no more than 15 minutes and turn Erase Data on. (Technically, the iPad deletes your encryption key, not the actual data, but that’s faster and just as effective.)

All modern iOS devices also come with a second layer of encryption, called Data Protection. While the basic encryption enabled by turning on passcodes protects all of the data on the device (including your apps), it can be bypassed by jailbreaking. Data protection encrypts your e-mail messages and their attachments; it can’t be broken even if the passcode is stripped by jailbreaking. Data protection is also available for programmers to use in apps, but few take advantage of it. (At this time, there aren’t any jailbreaks for the iPad 2, so the basic encryption is still safe; but that probably won’t last forever).

Enhance the passcode

To make the iPad’s built-in security features even more powerful, you can use Apple’s (now poorly named)iPhone Configuration Utility. Designed to help enterprises manage iOS devices, it opens up a suite of additional security and business settings, even for individual users.

To start, click on Configuration Profile -> New, and select Passcode from the list that appears. In the subsequent Passcode pane, you have all kinds of options; the settings here override your iPad’s. At the very least, you can specify a minimum length to the passcode.

To activate these password settings, you’ll have to fill in some information on the General tab too—specifically, the name and identifier of the profile. If this is a device that only you will use, you can set the Security drop-down to Always. (That allows you to remove the profile whenever you want.) If you’re configuring an iPad to be used by someone else, you can set it for Never or With Authorization (and then provide a password) so that someone else can’t change the settings without your permission.

Installing the profile is easy: Click Share to e-mail it to your iPad. On the tablet, you then open Mail, find the message, click on its attachment, and select Install. You can also export the profile to a downloadable file and install with the iPad’s copy of Safari.

Enable remote wipe

Remote wiping is an important security tool that allows you to delete the data on a lost iPad if and when it connects to the Internet. If you have a MobileMe account, you can set this up by enabling Find My iPad in Settings -> Mail, Contacts, Calendars -> MobileMe. Business users who connect to a Microsoft Exchange server (or Exchange alternatives such as Kerio Connect) can wipe their devices using Exchange ActiveSync support. This is managed on the server, not your device, so you’ll need to work with your IT administrator.

Remote wipe only works if there’s a network connection. That’s one reason why some companies purchase 3G iPads with data plans only.

Good safety practices

That takes care of the set-up. But there are also things you can do in daily use to make your iPad more secure.

One thing that means is to make your network connections as secure as possible. One of the best ways is to use a VPN

Another way is to use secure connections for e-mail. Microsoft Exchange servers encrypt data by default. If you use an IMAP or POP3 server, and it supports SSL, you can go to Settings > Mail, Contacts, Calendars > your account > Advanced on your iPad and enable it there.

Although Data Protection encrypts your e-mail attachments, the moment you send them to an app such as Pages, it is protected by the iPad’s basic encryption only. If you’re reallyworried about such documents, you can use a special secure e-mail server tool like Good for Enterpriseand its free companion iPad app. Good locks encrypted e-mail attachments (and files downloaded from its secure browser) inside the app, which means you can read them, but not edit them.

If you do lose your iPad, one of the first things you should do is change your password on any services—such as Dropbox or iDisk—that you connected to from it.

Finally, consider getting the 1Password Pro () app. It enables good password habits (a different, complex password for every site), it syncs with your Mac and other devices over the network or via DropBox, and it stores secure notes and other information as well as passwords. It even includes its own embedded Web browser for logging into sites without having to copy-and-paste your credentials.

disabled

How to enable disabled USB Ports in a Computer

5:11:00 PM

Computer^News^FAQ

SafeGuard Disk Encryption for Mac 5.5

Using SafeGuard

Limitations

McAfee Internet Security for Mac 2012

Protect yourself

Firewall and Firefox

How to keep your Mac safe from Web security flaws

How to ensure rogue security certificates don't subvert your encryption

Trust, but verify

Secure yourself

Removing CAs

Future Efforts

How to keep your iPad safe

Passcodes and encryption

Enhance the passcode

Enable remote wipe

Good safety practices

How to enable disabled USB Ports in a Computer

About me

Follow Us

Press

recent posts

Text Widget

Pages

PCWorld How-To's and Tips

PCWorld Latest Technology Reviews

Like us on Facebook

Flickr Images

Computer^News^FAQ

SafeGuard Disk Encryption for Mac 5.5

Using SafeGuard

Limitations

McAfee Internet Security for Mac 2012

Protect yourself

Firewall and Firefox

How to keep your Mac safe from Web security flaws

How to ensure rogue security certificates don't subvert your encryption

Trust, but verify

Secure yourself

Removing CAs

Future Efforts

How to keep your iPad safe

Passcodes and encryption

Enhance the passcode

Enable remote wipe

Good safety practices

How to enable disabled USB Ports in a Computer

About me

Follow Us

Press

recent posts

Text Widget

Subscribe To

Pages

PCWorld How-To's and Tips

PCWorld Latest Technology Reviews

Like us on Facebook

Flickr Images