19.8 C
London
Sunday, September 24, 2017
Home Tags Public Key Infrastructure

Tag: Public Key Infrastructure

SHA-1 End Times Have Arrived

For the past couple of years, browser makers have raced to migrate from SHA-1 to SHA-2 as researchers have intensified warnings about collision attacks moving from theoretical to practical. In just weeks, a transition deadline set by Google, Mozilla and Microsoft for the deprecation of SHA-1 is up. Starting on Jan. 24, Mozilla’s Firefox browser will be the first major browser to display a warning to its users who run into a site that doesn’t support TLS certificates signed by the SHA-2 hashing algorithm. The move protects users from collision attacks, where two or more inputs generate the same hash value. In 2012, Bruce Schneier projected a collision attack SHA-1 would cost $700,000 to perform by 2015 and $143,000 by 2018. In 2015, researchers said tweaks to existing attacks and new understanding of the algorithm could accelerate attacks and make a full-on collision attack feasible for somewhere between $75,000 to $125,000. Bocek and other experts warn the move SHA-2 comes with a wide range of side effects; from unsupported applications, new hardware headaches tied to misconfigured equipment and cases of crippled credit card processing gear unable to communicate with backend servers. They say the entire process has been confusing and unwieldy to businesses dependent on a growing number of digital certificates used for not only their websites, but data centers, cloud services, and mobile apps. “SHA-1 deprecation in the context of the browser has been an unmitigated success. But it’s just the tip of the SHA-2 migration iceberg. Most people are not seeing the whole problem,” said Kevin Bocek, VP of security strategy and threat intelligence for Venafi. “SHA-1 isn’t just a problem to solve by February, there are thousands more private certificates that will also need migrating.” Nevertheless, it’s browsers that have been at the front lines of the SHA-1 to SHA-2 migration. And starting next month, public websites not supporting SHA-2 will generate various versions of ominous warnings cautioning users the site they are visiting is insecure. According to Venafi Labs research team, 35 percent of the IPv4 websites it analyzed in November are still using insecure SHA-1 certificates. However, when researchers scanned Alexa’s top 1 million most popular websites for SHA-2 compliance it found only 536 sites were not compliant. Exceptions to Every Rule But still there are companies concerned about disruption to their business after the deadline asking for exceptions and exploring alternatives to full SHA-2 support. “What you are seeing is various companies, for one reason or another, unable to complete the migration” said Patrick Donahue, security engineering product lead at Cloudflare. “The browser makers have created an exception process that allows companies to make appeals for exceptions that allow CAs (certificate authorities) to issue them.” For example, last year Mozilla allowed a security firm to issue nine new SHA-1 certificates to payment processor Worldpay to use in 10,000 of its payment terminals worldwide. Worldpay argued because it missed a Dec. 31, 2015 cutoff for obtaining SHA-1 certificates, and said it needed SHA-1 certificates to buy more time to make the transition to SHA-2 or risk having thousands of its terminals go dark. After considerable debate, Mozilla granted the exception and issued SHA-1 certificates after the cutoff date. According to Cloudflare, as many as 10 percent of credit card payment systems may also face problems as browsers reject SHA-1 certificates used in terminals similar to Worldpay’s. “For credit card processing, it’s not as simple as a software update. It will require sending out new credit card processing machines that support SHA-2,” Donahue said. For social networking behemoth Facebook, it wasn’t so much about the company looking for an exception, rather a solution that could allow it to keep users stuck on older computers and aging handhelds connected to its service. In late 2015, Facebook estimated up to 7 percent of browsers used by its customers, particularly in developing countries, would not able to use the newer SHA-2 standard. At the time, Facebook chief security officer Alex Stamos said, “We don’t think it’s right to cut tens of millions of people off from the benefits of the encrypted Internet, particularly because of the continued usage of devices that are known to be incompatible with SHA-256.” The solution for Facebook is similar to what a number of companies have sought, a stopgap fix until SHA-2 adoption is ubiquitous. Facebook said it has found success running a large TLS termination edge with certificate switching, where it intelligently chooses which certificates a person sees based upon Facebook’s guess as to the capabilities of user’s browser. “This allows us to provide HTTPS to older browsers using SHA-1 while giving newer browsers the security benefits of SHA-256,” Stamos explained. Cloudflare and Mozilla have both developed a similar techniques for customers concerned that line-of-business websites will stop working after the deprecation deadline. “The biggest excuse among web server operators was the need to support Internet Explorer on Windows XP (pre-SP3), which does not support SHA-2.  However, websites with this requirement (including www.mozilla.org) have developed techniques that allow them to serve SHA-2 certificate to modern browsers while still providing a SHA-1 certificate to IE/XP clients,” said J.C. Jones, cryptographic engineering manager at Mozilla. Workarounds work for browsers, but different SHA-2 transition challenges persist within the mobile app space. Apps Must Catch Up on SHA-2 Support When a browser rejects a SHA-1 certificate, the warning message is easy to spot. That’s not the case with apps. While Google’s Android and Apple’s iOS operating systems have supported SHA-2 for more than a year, most apps still do not. “With apps, you don’t get to see what the actual trusted connections are. It requires blind faith,” Venafi’s Bocek said. Alternatively, it should be a matter of trust and verify, he said. He reminds how bad things got in 2014 when Fandango and Credit Karma assured users that their data was secure and being sent over encrypted SSL connections when in fact they disabled their apps’ SSL certificate validation. SHA-1 used by apps is a far cry from no protection. But still, the absence of SHA-2 introduces risk that someone could mint a forged SHA-1 certificate to connect with an app using a SHA-1 certificate. An attacker spoofing the DNS of a public Wi-Fi connection could launch a man-in-the-middle attack, and unlike with a browser, the use of untrusted TLS certificates would go unnoticed, Bocek said. App developers don’t have to worry about pressure from browser makers. More often, it’s about what individual platforms and app makers decide to enforce. In December, Apple backtracked on its plan to enforce a year-end deadline that would have required developers to adopt App Transport Security, which included SHA-2 support. It did not set a new deadline. As with Apple, it’s unclear when Google might force app developers to use SHA-2 or if it will reject SHA-1 certificates used to sign apps. Salesforce warned its developer community and users if they wanted to continue to have error-free access to Salesforce, they needed to ensure their operating systems, browsers, and middleware were capable of accepting HTTPS certificates with the SHA-2 hashing algorithm or risk being blocked. For Facebook, unlike its stance on SHA-1 deprecation for its website, it set a firm sunset date of Jan. 1, 2016 for SHA-1 for developers using its SDKs. After that date, Facebook required apps that connect to it to support SHA-2 connections. “If your app relies on SHA-1 based certificate verification, then people may encounter broken experiences in your app if you fail to update it,” said Adam Gross, a production engineer at Facebook. Internal PKIs Aren’t Immune Enterprises are also not under the same immediate pressure to update their internal PKI used for internal hardware, software and cloud applications. But security experts warn that doesn’t make them immune to major certificate headaches. One of those hassles is the fact the number of certificates has ballooned to an average of more than 10,000 per company, which makes the switch from SHA-1 to SHA-2 a logistical nightmare, according to Venafi. The growth of SSL and TLS traffic has been a mixed blessing, Bocek said. “More security is always better, but one blind spot in a sea of thousands of certificates used within the enterprise could be disastrous for the security of a business.” That’s prompted Microsoft to take a hardline approach to SHA-1 deprecation. It announced an ultimate kill date for SHA-1 for its operating system in 2014: “CAs must stop issuing new SHA-1 SSL and Code Signing end-entity certificates by 1 January 2016 … For SSL certificates, Windows will stop accepting SHA-1 end-entity certificates by 1 January 2017. This means any time valid SHA-1 SSL certificates must be replaced with a SHA-2 equivalent by 1 January 2017 … For code signing certificates, Windows will stop accepting SHA-1 code signing certificates without time stamps after 1 January 2016.  SHA-1 code signing certificates that are time stamped before 1 January 2016 will be accepted until such time when Microsoft decides SHA1 is vulnerable to pre-image attack.” “This is an operational issue. It isn’t as simple as patching or upgrading systems,” Bocek said. The migration requires a certificate inventory assessment, a review of policies, application and system testing and automation, he said. But he warns of the perils of procrastination. “This is a non-trivial migration,” Bocek said. Think of 2017 not as the end of the race, rather when SHA-2 migrations begin to hit their stride, he said.

The Electronic Frontier Foundation aims to protect Web traffic by encrypting the entire Internet using HTTPS.

Chrome now puts a little warning marker in the Address Bar next to any non-secure HTTP address.

Encryption is important, and not only for Web surfing.
If you encrypt all of the sensitive documents on your desktop or laptop, a hacker or laptop thief won't be able to parley their possession into identity theft, bank account takeover, or worse.

To help you select an encryption product that's right for your computer, we've rounded up a collection of current products.

As we review more products in this area, we'll keep the list up to date.

No Back Doors

When the FBI needed information from the San Bernardino shooter's iPhone, they asked Apple for a back door to get past the encryption.

But no such back door existed, and Apple refused to create one.

The FBI had to hire hackers to get into the phone.

Why wouldn't Apple help? Because the moment a back door or similar hack exists, it becomes a target, a prize for the bad guys.
It will leak sooner or later.
In a talk at Black Hat this past summer, Apple's Ivan Krstic revealed that the company has done something similar in their cryptographic servers. Once the fleet of servers is up and running, they physically destroy the keys that would permit modification.

Apple can't update them, but the bad guys can't get in either.

All of the products in this roundup explicitly state that they have no back door, and that's as it should be.
It does mean that if you encrypt an essential document and then forget the encryption password, you've lost it for good.

Two Main Approaches

Back in the day, if you wanted to keep a document secret you could use a cipher to encrypt it and then burn the original. Or you could lock it up in a safe.

The two main approaches in encryption utilities parallel these options.

One type of product simply processes files and folders, turning them into impenetrable encrypted versions of themselves.

The other creates a virtual disk drive that, when open, acts like any other drive on your system. When you lock the virtual drive, all of the files you put into it are completely inaccessible.

Similar to the virtual drive solution, some products store your encrypted data in the cloud.

This approach requires extreme care, obviously.

Encrypted data in the cloud has a much bigger attack surface than encrypted data on your own PC.

Which is better? It really depends on how you plan to use encryption.
If you're not sure, take advantage of the 30-day free trial offered by each of these products to get a feel for the different options.

Secure Those Originals

After you copy a file into secure storage, or create an encrypted version of it, you absolutely need to wipe the unencrypted original. Just deleting it isn't sufficient, even if you bypass the Recycle Bin, because the data still exists on disk, and data recovery utilities can often get it back.

Some encryption products avoid this problem by encrypting the file in place, literally overwriting it on disk with an encrypted version.
It's more common, though, to offer secure deletion as an option.
If you choose a product that lacks this feature, you should find a free secure deletion tool to use along with it.

Overwriting data before deletion is sufficient to balk software-based recovery tools. Hardware-based forensic recovery works because the magnetic recording of data on a hard drive isn't actually digital.
It's more of a waveform.
In simple terms, the process involves nulling out the known data and reading around the edges of what's left.
If you really think someone (the feds?) might use this technique to recover your incriminating files, you can set your secure deletion tool to make more passes, overwriting the data beyond what even these techniques can recover.

Encryption Algorithms

An encryption algorithm is like a black box.

Dump a document, image, or other file into it, and you get back what seems like gibberish. Run that gibberish back through the box, with the same password, and you get back the original.

The U.S. government has settled on Advanced Encryption Standard (AES) as a standard, and all of the products gathered here support AES.

Even those that support other algorithms tend to recommend using AES.

If you're an encryption expert, you may prefer another algorithm, Blowfish, perhaps, or the Soviet government's GOST.

For the average user, however, AES is just fine.

Public Key Cryptography and Sharing

Passwords are important, and you have to keep them secret, right? Well, not when you use Public Key Infrastructure (PKI) cryptography.

With PKI, you get two keys. One is public; you can share it with anyone, register it in a key exchange, tattoo it on your forehead—whatever you like.

The other is private, and should be closely guarded.
If I want to send you a secret document, I simply encrypt it with your public key. When you receive it, your private key decrypts it.
Simple!

Using this system in reverse, you can create a digital signature that proves your document came from you and hasn't been modified. How? Just encrypt it with your private key.

The fact that your public key decrypts it is all the proof you need. PKI support is less common than support for traditional symmetric algorithms.

If you want to share a file with someone and your encryption tool doesn't support PKI, there are other options for sharing. Many products allow creation of a self-decrypting executable file. You may also find that the recipient can use a free, decryption-only tool.

What's the Best?

Right now there are three Editors' Choice products in the consumer-accessible encryption field.

The first is the easiest to use of the bunch, the next is the most secure, and the third is the most comprehensive.

AxCrypt Premium has a sleek, modern look, and when it's active you'll hardly notice it.

Files in its Secured Folders get encrypted automatically when you sign out, and it's one of the few that support public key cryptography.

CertainSafe Digital Safety Deposit Box goes through a multistage security handshake that authenticates you to the site and authenticates the site to you. Your files are encrypted, split into chunks, and tokenized.

Then each chunk gets stored on a different server.

A hacker who breached one server would get nothing useful.

Folder Lock can either encrypt files or simply lock them so nobody can access them.
It also offers encrypted lockers for secure storage.

Among its many other features are file shredding, free space shredding, secure online backup, and self-decrypting files.

The other products here also have their merits, too, of course. Read the capsules below and then click through to the full reviews to decide which one you'll use to protect your files. Have an opinion on one of the apps reviewed here, or a favorite tool we didn't mention? Let us know in the comments.

FEATURED IN THIS ROUNDUP

Steganos Safe 18

Having your laptop stolen is traumatic; having the thief gain access to your sensitive documents could be catastrophic.

To avert the possibility of catastrophe, use an encryption tool to protect your most important files. With Steganos Safe 18, you can create any number of encrypted storage containers.
Steganos combines an impressive variety of security options with an interface that's very easy to use.

Your $39.95 purchase lets you install Steganos Safe on up to five PCs.

This is a one-time cost, which is a common model for encryption tools.

Editors' Choice utility Folder Lock also costs $39.95, and Ranquel Technologies CryptoForge goes for $39.70. You'll pay $45 for Cypherix PC, and $59.95 for CryptoExpert. Note, though, that those are single licenses.

The five-license Steganos package is quite a bargain.

In addition to being available a standalone product, Steganos Safe is an integral part of the full Steganos Privacy Suite.

This suite also includes Steganos Password Manager 18 and a number of other useful tools.

What Is Encryption?

Throughout history, rulers and generals have needed to communicate their plans in secret, and their enemies have devoted great resources to cracking their secret communication systems.

A cipher that simply replaces every letter with a different letter or symbol is easy enough to crack based on letter frequency.

France's Louis XIV used a system called The Great Cipher, which held out for 200 years before anyone cracked it.

Father-son team Antoine and Bonaventure Rossignol conceived the idea of encoding syllables rather than letters, and letting multiple code numbers represent the same syllable.

They also included nulls, numbers that contributed nothing to the cipher.

But even this long-unbroken cipher pales in comparison with modern encryption technology.

Advanced Encryption Standard (AES), the US government's official standard, runs blocks of data through multiple transformations, typically using a 256-bit key.

Bruce Schneier's Blowfish algorithm should be even tougher to crack, as it uses a 448-byte key.

Whatever the size of the key, you must get it to the recipient somehow, and that process is the weakest point in the system.
If your enemy obtains the key, whatever its size, you lose. Public Key Infrastructure (PKI) cryptography has no such weakness.

Each user has two keys, a public key that's visible to anybody and a private key that nobody else has.
If I encrypt a file with your public key, you can decrypt it with the private key.

Conversely, if I encrypt a file with my private key, the fact that you can decrypt it with my public key proves it came from me—a digital signature.

Getting Started with Steganos Safe

The Steganos encryption utility's installation is quick and simple. Once finished, it shows you a simple main window that has two big buttons, one to create a new safe and one to open a hidden safe.

When a safe is open, it looks and acts precisely like a disk drive. You can move files into and out of it, create new documents, edit documents in place, and so on.

But once you close the safe, its contents become totally inaccessible. Nobody can unlock it without the password, not even Steganos.

Like Editors' Choice tools CertainSafe Digital Safety Deposit Box, AxCrypt, and Folder Lock, Steganos uses AES for all encryption. However, it cranks the key size up from the usual 256 bits to 384 bits.

CryptoExpert and CryptoForge offer four different algorithms, and Advanced Encryption Package goes over the top with 17 choices.

Few users have the knowledge to make an informed choice of algorithm, so I see no problem sticking with AES.

Steganos warns if you try to close a safe while you still have files from the safe open for editing.
In addition to the basic safe, Steganos can optionally create portable safes and cloud safes.
I'll cover each safe type separately.

Create a Safe

The process of creating a new safe for storing your sensitive documents is quite simple, with a wizard that walks you through the steps. You start by assigning a name and drive letter to the safe—the program's main window shows you the name.

By default, Steganos creates the file representing your safe in a subfolder of the Documents folder, but you can override that default to put it wherever you want, including on a network drive.

Next, you define the safe's capacity, from a minimum of 2MB to a maximum that depends on your operating system. Unlike Cypherix PE and CryptoExpert, with Steganos the initial capacity doesn't have to be a hard limit. You can create a safe whose size grows dynamically.

Folder Lock works a bit differently. While you must set a maximum size at creation, it only uses as much space as its current content requires.

A newly created Cypherix volume requires formatting. With Steganos, the safe is ready for use immediately.

The next step is to select a password.
If you've created a master password for
Steganos Password Manager, the password dialog should look familiar.
Steganos rates password strength as you type.
If you wish, you can define the password by clicking a sequence of pictures rather than typing it in.

There's also an option to enter the password using a virtual keyboard.

Folder Lock and InterCrypto Advanced Encryption Package 2016 also offer a virtual keyboard.

Here's a useful option. You can choose to store the password on a removable drive, making that drive effectively the safe's key.

By default, a safe opened in this way closes automatically when you remove the key.
It's not two-factor authentication, as you can still unlock the safe using just the password, but it's certainly convenient.
In a similar situation, you can configure InterCrypto CryptoExpert 8 to require both the master password and the USB key.

Digging into the program's settings, you can simplify the process by disabling advanced wizard options.
If you do so, Steganos chooses default values for each new safe's drive letter and filename.

There's a special option that only appears for safes smaller than 3MB.
If you've chosen an acceptable size, a link appears explaining how you can create a hidden safe.
Steganos can hide a small-enough safe inside a video, audio, or executable file.

After creating the safe, you click it, choose Hide from the menu, and select a carrier file.
Steganos stuffs the entire safe into the carrier, without affecting the carrier's ability to function as a program or audio/video file.

To open it, you click Open a Hidden Safe on the main window, select the carrier, and enter the password. Just don't forget where you hid the safe.

Portable Safes

For additional security, consider creating a portable safe that you only bring out when you need to access it.

The process is similar. You start by selecting the target device, which can be a USB storage device or an optical drive. You define the size and create a password, just as for a regular safe.

But then the process diverges.

Steganos creates and opens what it calls a prepackaging drive, using the drive letter of your choice.
Showing its age, the tool warns that portable safes don't support Windows NT 4.0 or Windows 95/98/Me. You click to open the prepackaging drive and drag the desired files into it. When you click Next, Steganos creates the necessary files on the target device. You're done!

If the size of the portable safe is less than about 512MB, Steganos creates what it calls a SelfSafe by default.

As with the hidden option for regular safes, you won't even see this as a choice if your desired size is too large.

The SelfSafe is a single executable file called SteganosPortableSafe.exe that contains both the necessary decryption code and the data representing the safe's contents. Otherwise, it stores the contents in a folder called Portable_Safe and adds a file called usbstarter.exe.

Either way, launching the file lets you enter the password and open the portable safe.

In testing, I did run into one surprise; a portable safe is not completely portable.
It requires the Steganos encryption engine. You can only open and work with your portable safe on a PC where you've installed the program.

Cloud Safes

As noted, you can open a portable safe on any PC where you've installed Steganos Safe.

Creating a cloud safe is another way to share your encrypted files between PCs.
Steganos supports the cloud storage services Dropbox, Google Drive, or Microsoft OneDrive. Whichever you choose, you must install that cloud service's desktop app.

The help points out that Google Drive and OneDrive must re-sync the entire safe when there's any change, while DropBox can selectively sync changes only.

My test PC didn't have any of the desktop apps installed, and the cloud safe creation dialog reflected this fact.

For testing purposes, I installed the Dropbox app.

As with a regular safe, you select a name and drive letter and then choose the safe's size.

For a cloud safe, you don't get the option to have the safe expand as needed.

Create your password, wait for the safe's initialization, and you're ready to go.

The safe syncs to the cloud each time you close it, and you can use it on any PC that has both Steganos and the proper cloud app installed.

Advanced Features

Click a safe and click Settings to bring up the administration dialog. Here you can change the password, name, and file location for the safe, but that's not all. On the main page of the dialog you can color-code the safe, and choose whether Windows should see it as a local drive or a removable drive. On the Events tab, you can choose whether to open the safe when you log on, and whether to close it on events such as screen saver activation or going into standby.

There's an option to define an action that occurs after the safe opens, and after it closes.

For example, you could configure it to automatically launch a file that resides within the safe after opening it, or automatically make a backup copy after closing it.

Perhaps most interesting is the Safe in a Safe feature.

This defines a separate safe, hidden within the normal safe, occupying a user-defined percentage of available space, and having its own password.

Depending on which password you use to open the safe, you either open the Safe in a Safe, or the original safe that contains it.
Sneaky! But take care.
If you overfill the outer safe, its contents can wipe out the super-secret Safe in a Safe.

Steganos Shredder

It's all well and good to put your most sensitive files into an encrypted safe, but if you leave the unencrypted originals on disk, you haven't accomplished much, security-wise.

Even if you delete the originals, they're not really gone, because their data remains on disk until new data overwrites it.

For true privacy, you must use a secure deletion tool that overwrites file data before deletion, something like this program's file-shredder component.

The easiest way to use the shredder is to right-click a file or folder and choose Destroy from the menu that appears.
Steganos overwrites the file's data once and then deletes it.

This should be sufficient to foil software-based file recovery systems, though it would still be theoretically possible for a hardware-based forensic tool to get back some or all of the data.

Folder Lock, by contrast, lets you choose up to 35 overwrite passes, which is overkill, as there's no added benefit after seven passes.

Launching the full File Shredder from the main window's menu reveals that it does more than just securely delete files.

As with Folder Lock, Steganos can overwrite all the free space on a disk.

Doing so wipes out all traces of previously deleted files, in effect shredding them ex post facto.

This can be a lengthy process, so you may want to use the scheduler to set it for a time when you're not using the computer. You can also schedule daily or weekly free space shredding. Note that if you stop and restart the free space shredding process, it skips quickly past previously shredded areas.

Finally, there's the Complete Shredder nuclear option.

Choose this to completely wipe out all data on a drive, including partition data.

A drive that's been shredded in this way must be formatted before you can do anything with it. Like shredding free space, this process can take quite a while.

By observation, you can't shred the active Windows volume, which makes sense. When I tried, there was no error message, but it did nothing.

Comprehensive Encrypted Storage

Steganos Safe 18 focuses on the singular task of creating encrypted storage containers for your sensitive files, and it does that task very well.
It's easier to use than most of its competitors, and its Safe in Safe and hidden safe options are unique. You can only use its portable safe and cloud safe features on PCs that have the program installed, but your purchase gets you five licenses.

However, Folder Lock does most of what Steganos does, and quite a lot more.
It features include encryption of individual files and folders, secure storage of private data, a history cleaner, and (at an extra cost) secure online backup.

AxCrypt Premium is even easier to use than Steganos, and supports public key cryptography.

And CertainSafe Digital Safety Deposit Box protects your cloud-stored encrypted files against any possibility of a data breach.

These three are our Editors' Choice products for encryption, but Steganos is a worthy contender.

Back to top

PCMag may earn affiliate commissions from the shopping links included on this page.

These commissions do not affect how we test, rate or review products.

To find out more, read our complete terms of use.

As a traveling computer security consultant for over 20 years, I’ve had the chance to visit a lot of different operations and see what works and doesn’t work.
I’m always looking for common denominators for successes and failures, and I share these lessons as I learn them. But I realize I’ve unconsciously absorbed one home truth without realizing it -- and it’s about contractors.

The outsourcing of jobs to third-party companies has continued unabated for years.
It’s not unusual for me to learn that almost nobody in the team running the place is an employee. One contractor manages the network, another deploys and manages PCs, another handles directory services, and another handles security. Here's what I've learned: Too many contractors can be detrimental. I say that despite the fact that, in many cases, contractors are smarter and more skilled than the employees they replace. When they come with specialized skill sets for a special project, they'll get a project done quicker than regular employees can.

Contractors are absolutely necessary, but there's a limit. After all these years of observing environments, the strongest and best protected companies tend to be those with the highest percentage of full-time employees versus contractors. Why? Organizational knowledge Easily one of the biggest reasons to use employees is to keep the history and experience of a team within a company over the long haul.

Contractors come and go; often an entire team is replaced with one new contract. Whatever contractors learn is gone when they walk out the door. A full-time, long-term employee collects experience that benefits the team.
I can’t tell you how many times someone has suggested what sounded like an awesome solution to a problem, only to have a longtime employee rebut the solution with something no one else had thought about.
Sometimes it’s an employee who simply tells the team how to navigate a political situation no one else understood.

Every team has an employee who knows where the bodies are buried. When something needs to get done ASAP, give me a long-term employee who knows who we need to call. Want to know why that weird script is kicking off every night on every server, or what that computer covered in dust in the back of computer room is doing? Talk to an employee who's been there.

Documentation is better -- but you have to find it first! When you’re sitting in a darkened computer closet wondering what that piercing beeping sound is, ask an employee. Want to know why that DNS server’s operating system hasn’t been updated in a year ...? (You get the idea.) Ramp-up time New employees and contractors always start with the same quantity of institutional knowledge: zero.
It takes time to educate them about the systems they'll be handling, to show them where the documentation is hiding, and to cover what they need to do and why.

The more contractors you use, the more you need to do that again and again as they rotate in and out. For one client, I spend a few weeks each year educating the most recent new contractor on how to operate the company's PKI.
It takes one to two weeks to provide a complete education.
So far, I've repeated this process consistently for 10 years. My employer, a contractor, certainly doesn’t mind me charging those hours for education, but so far the only PKI consistency at this client is me -- another contractor. Contractual obligations Most contractors have specific obligations and don’t like to deviate very much.
In fact, they can get in trouble for deviating.

But narrowly specific duties, without the ability to work freely, can have unforeseen consequences. For example, I was once hired to access a very large organization’s Active Directory security and patch management processes.

During that assessment, I came across very harmful malware spread across most of the company’s servers.

The patch management contractor admitted noticing the malware for the last year. I asked why nothing had been said about it.

The reply: Their job was patch management and they'd gotten their hand slapped for talking about something beyond their contractual duties.

Turned out the company was completely and utterly owned by an outside foreign entity and had been for years. Divided loyalty No matter how much a contractor likes working for a particular customer, that individual's loyalty will be to the organization that signed the paycheck.
If there's a conflict between the customer and the contractor's employer, you can be sure which side the contractor will choose. Incentive to hide weak co-workers I’ve also seen teams of contractors who end up "hiding" the weakest among them.

They know this person is ill-suited for the role he or she is supposed to perform, but that person has been been touted as a "subject matter expert" with a bill rate to match.

Typically, a weak player can be covered for pretty easily, particularly if the job is relatively short term. Right now, I know many contractors reading this are shaking their heads in sad agreement. It's different with full-time employees. We've all tolerated weak co-workers, but we have no incentive to hide them. Peers will eventually bring a weak employee's poor performance to management’s attention. The insider threat I’ve only worked on a dozen or so insider threat cases in my career, but several involved subcontractors.

Typically, those subcontractors learned logon credentials and how to remotely access systems, which they abused either during or after their employment.
Secure messaging app invites you to dive in and figure out if it's done anything wrong Signal developer Open Whisper Systems has quietly posted some important documents for developer consumption: the specifications of its signature verification, key agreement, and secret key protocols. The posts are dated 20 November, although a Tweet from 4 November suggests the documentation was stealth-published earlier. The three specs cover the XEdDSA and VXEdDSA signature schemes; the Extended Triple Diffie-Hellman (X3DH) key agreement protocol; and what the outfit calls the “Double Ratchet” protocol, which Signal uses for message encryption. With the Signal Service API and Signal Protocol API already public, Whisper Systems is giving outsiders a deep view of the operations of the popular privacy-messaging system. So what's in the box? X3DH kicks things off, providing key agreement between Bob and Alice, even if only one is online at the time.
It uses the familiar public key infrastructure approach – Alice retrieves Bob's key from the server he published it to – and they use that information to establish communication and choose their shared private key. The document's in-short version of what happens is a three-phase process: Bob publishes his identity key and prekeys to a server; Alice fetches a "prekey bundle" from the server, and uses it to send an initial message to Bob; Bob receives and processes Alice's initial message. X3DH can use X25519 or X448 elliptic curves, and for hashing it requires SHA 256 or SHA 512, and the document notes that the protocol “provides forward secrecy and cryptographic deniability”. The signatures X3DH uses are described in XEdDSA and VXEdDSA Signature Schemes.

The focus of the schemes is twofold: to ensure that the encrypted signatures look random to anybody sniffing them (a “verifiable random function”); and to make the schemes resistant to timing side-channel attacks. And we still haven't gotten to the users exchanging messages, because this only gets us as far as Bob and Alice setting up their message-passing.

The last part, protecting the messages, is the job of the Double Ratchet Algorithm. Defeating the snoops To make Signal resistant to decryption using a bunch of sniffed messages, the algorithm creates new keys for each message, and here Bob and Alice's public Diffie-Hellman values come back into play: “The parties also send Diffie-Hellman public values attached to their messages.

The results of Diffie-Hellman calculations are mixed into the derived keys so that later keys cannot be calculated from earlier ones.

These properties gives some protection to earlier or later encrypted messages in case of a compromise of a party's keys.” A “KDF chain” (key derivation function) in Double Ratchet protects Bob and Alice's message keys “even if the adversary can control the KDF inputs”, the document says; because a key is never used twice, the messages get forward security; and as long as the system is running enough entropy, Double Ratchet's also designed to be resistant to a snoop breaking into a server and recovering user messages. For non-cryptographers, the term “Double Ratchet” comes from how the protocol makes sure each message gets a new key: their Diffie-Hellman keys are “ratcheted” by each new message exchange; and so are the send/receive chains (the “symmetric-key ratchet”). The Register will watch with interest to see if any cryptanalysts can spot any gaps in the specs. ® Sponsored: Customer Identity and Access Management
The long-awaited SHA-1 deprecation deadline of Jan. 1, 2017, is almost here.

At that point, we’ll all be expected to use SHA-2 instead.
So the question is: What is your browser going to do when it encounters a SHA-1 signed digital certificate? We’ll delve into the answers in a minute.

But first, let’s review what the move from SHA-1 to SHA-2 is all about. Getting from SHA-1 to SHA-2 SHA-1 is a cryptographic hash officially recommended by NIST.
It’s used to verify digital content, as well as digital certificates and certificate revocation lists (CRLs). Whenever a PKI certification authority (CA) issues a certificate or CRL, it signs it with a hash to assist “consuming” applications and devices with trust verification.  In January 2011, SHA-2 became the new, recommended, stronger hashing standard.
SHA-2 is often called “the SHA-2 family of hashes” because it contains hashes of many different lengths, including 224-bit, 256-bit, 384-bit, and 512-bit digests.

The most popular one is 256 bits by a large margin. Who declared Jan. 1, 2017 the drop-dead date for SHA-1? Three of the top browser vendors and dozens of other software vendors.

They belong to a vendor consortium called the CA Browser Forum, which publishes requirements for public CAs in its frequently updated Baseline Requirements document. The CA Browser forum’s SHA-1 deprecation requirements apply to all but two types of certificates (covered below), although some browser vendors care only about web server certificates. Per the CA Browser forum, no public CA is allowed to issue SHA-1-signed certificates after Jan. 1, 2016, for certificates that expire after Dec. 31, 2016, although in some browsers, any SHA-1 certificate expiring after Dec. 31, 2017, is flagged, regardless of when it was issued. The CA Browser Forum specifically excludes root CA server certificates and cross CA certificates from the SHA-1 deprecation requirements.

This means you do not have to worry about your root CA’s certificate, although you probably need to worry about how it signs subordinate CA certificates and CRLs. Your browser’s reaction Some major browser vendors have been issuing warnings and error messages for two years.

Today, some browsers put an X through the HTTPS indicator (Google Chrome), don’t display the lock icon (Microsoft Edge and Internet Explorer), or simply remove the HTTPS portion of the URL (Apple Safari). Some browsers, such as Firefox, don’t show any indication when consuming an SHA-1 certificate; others may or may not depending on whether you're using a PC or mobile version of the browser.
In some cases, the protection given by the SHA-1 TLS certificate is still active even though the browser appears to indicate that it is not (for example, Chrome, Edge, or Internet Explorer). SHA-1 deprecation in the major browsers Certificate types and deprecation evaluation What certificate types will be evaluated for SHA-1 deprecation? It depends on the browser.  The CA Browser forum says all certificates will be evaluated except for root CA server and cross-CA certificates.

But I have seen browsers that popped up an error message on SHA-1 root CA certificates when they were acting as an “intermediate” root CA in a three- or four-tier PKI hierarchy and on cross-CA certificates. Microsoft will only evaluate certificates that originate from a PKI chain registered in the Microsoft Trusted Root program.

Certificates originating from a PKI chain registered in the Microsoft Trusted Root program will be evaluated only if they contain the Server Authentication OID.

This is an important point because some TLS certificates may contain the Client Authentication or Workstation Authentication OIDs only. (See Microsoft’s SHA-1 deprecation policy.) Other browser vendors say they will inspect “all” certificates for SHA-1 deprecation, but in practice this always excludes the root CA server certificates and may technically mean only web server or Server Authentication OID certificates.
I’ve had a hard time nailing down browser vendors on exactly which certificates they will include in deprecation-checking. Mozilla did confirm it also checks for the deprecated Netscape Step-Up OID. Mozilla Firefox, Google Chrome, and Opera browsers will check both public and private certificates by default, although you can manually register private PKI chains (sometimes called enterprise chains) to be excluded from SHA-1 deprecation checking. You can find Mozilla’s latest SHA-1 deprecation statement here; Google’s can be found here. As of Jan. 1, 2017, “full” SHA-1 deprecation enforcement is supposed to happen, although Microsoft will actually begin full enforcement on Feb. 14, 2017 (the second Patch Tuesday of the year). Mozilla says it will begin full enforcement in January 2017, with no specific date, whereas Google (and Opera) will begin full enforcement by the end of January 2017. All browsers will eventually evaluate all certificates, public or private, with no exceptions allowed, although this is will probably be many years out.

Expect any new improvement in SHA-1 cracking to speed up timelines and incur policy updates.
The cloud has made it dead simple to quickly spin up a new server without waiting for IT.

But the ease of deploying new servers -- and the democratic nature of cloud management -- can be a security nightmare, as a simple configuration error or administrative mistake can compromise the security of your organization's entire cloud environment. With sensitive data increasingly heading to the cloud, how your organization secures its instances and overall cloud infrastructure is of paramount importance.

Cloud providers, like Amazon, secure the server hardware your instances run on, but the security of the cloud infrastructure your organization sets up on that infrastructure is all on you.

A broad array of built-in security services and third-party tools are available to secure practically any workload, but you have to know how to use them.

And it all starts with proper configuration. Analysis of real-world Amazon Web Services usage doesn’t paint a pretty picture.

Cloud security company Saviynt recently found among its customers an average of 1,150 misconfigurations in Elastic Compute Cloud (EC2) instances per AWS account.
It’s clear that the ease of spinning up EC2 instances for development and testing is coming at the expense of security controls that would otherwise be in place to protect on-premises servers.

AWS admins need to use available tools properly to ensure the security of their environments. Here we survey some of the most common configuration mistakes administrators make with AWS. Mistake 1: Not knowing who is in charge of security When working with a cloud provider, security is a shared responsibility. Unfortunately, many admins don’t always know what AWS takes care of and which security controls they themselves have to apply. When working with AWS, you can’t assume that default configurations are appropriate for your workloads, so you have to actively check and manage those settings. “It’s a straightforward concept, but nuanced in execution,” says Mark Nunnikhoven, vice president of cloud research at Trend Micro. “The trick is figuring out which responsibility is which.” More important, AWS offers a variety of services, each of which requires distinct levels of responsibility; know the differences when picking your service.

For example, EC2 puts the onus of security on you, leaving you responsible for configuring the operating system, managing applications, and protecting data. “It’s quite a lot,” Nunnikhoven says.
In contrast, with AWS Simple Storage Service (S3) customers focus only on protecting data going in and out, as Amazon retains control of the operating system and application. “If you don't understand how this model works, you're leaving yourself open to unnecessary risks,” Nunnikhoven says. Mistake 2: Forgetting about logs Too many admins create AWS instances without turning on AWS CloudTrail, a web service that records API calls from AWS Management Console, AWS SDKs, command-line tools, and higher-level services such as AWS CloudFormation. CloudTrail provides invaluable log data, maintaining a history of all AWS API calls, including the identity of the API caller, the time of the call, the caller’s source IP address, the request parameters, and the response elements returned by the AWS service.

As such, CloudTrail can be used for security analysis, resource management, change tracking, and compliance audits. Saviynt’s analysis found that CloudTrail was often deleted, and log validation was often disabled from individual instances. Administrators cannot retroactively turn on CloudTrail.
If you don’t turn it on, you’ll be blind to the activity of your virtual instances during the course of any future investigations.
Some decisions need to be made in order to enable CloudTrail, such as where and how to store logs, but the time spent to make sure CloudTrail is set up correctly will be well worth it. “Do it first before you need it,” says John Robel, a principle solutions architect for Evident.io. Mistake 3: Giving away too many privileges Access keys and user access control are integral to AWS security.
It may be tempting to give developers administrator rights to handle certain tasks, but you shouldn’t. Not everyone needs to be an admin, and there’s no reason why policies can’t handle most situations.
Saviynt’s research found that 35 percent of privileged users in AWS have full access to a wide variety of services, including the ability to bring down the whole customer AWS environment.

Another common mistake is leaving high-privilege AWS accounts turned on for terminated users, Saviynt found. Administrators often fail to set up thorough policies for a variety of user scenarios, instead choosing to make them so broad that they lose their effectiveness.

Applying policies and roles to restrict access reduces your attack surface, as it eliminates the possibility of the entire AWS environment being compromised because a key was exposed, account credentials were stolen, or someone on your team made a configuration error. “If you find yourself giving complete access to a service to someone, stop,” says Nunnikhoven. “Policies should include the least amount of permissions to get a job done.” Mistake 4: Having powerful users and broad roles AWS Identity and Access Management (IAM) is critical for securing AWS deployments, says Nunnikhoven.

The service -- which is free -- makes it fairly straightforward to set up new identities, users, and roles, and to assign premade policies or to customize granular permissions. You should use the service to assign a role to an EC2 instance, then a policy to that role.

This grants the EC2 instance all of the permissions in the policy with no need to store credentials locally on the instance. Users with lower levels of access are able to execute specific (and approved!) tasks in the EC2 instance without needing to be granted higher levels of access. A common misconfiguration is to assign access to the complete set of permissions for each AWS item.
If the application needs the ability to write files to Amazon S3 and it has full access to S3, it can read, write, and delete every single file in S3 for that account.
If the script’s job is to run a quarterly cleanup of unused files, there is no need to have any read permissions, for example.
Instead, use the IAM service to give the application write access to one specific bucket in S3.

By assigning specific permissions, the application cannot read or delete any files, in or out of that bucket. “In the event of a breach, the worst that can happen is that more files are written to your account. No data will be lost,” says Nunnkhoven. Mistake 5: Relying heavily on passwords The recent wave of data breaches and follow-up attacks with criminals using harvested login credentials to break into other accounts should have made it clear by now: Usernames and passwords aren’t enough.

Enforce strong passwords and turn on two-factor authentication to manage AWS instances.

For applications, turn on multifactor authentication.

AWS provides tools to add in tokens such as a physical card or a smartphone app to turn on multifactor authentication. “Your data and applications are the lifeblood of your business,” Evident.io’s Robel warns. Mistake 6: Exposed secrets and keys It shouldn’t happen as often as it does, but credentials are often found hard-coded into application source code, or configuration files containing keys and passwords are stored in publicly accessible locations.

AWS keys have been exposed in public repositories over the years.

GitHub now regularly scans public repositories to alert developers about exposed AWS credentials. Keys should be regularly rotated.

Don’t be the administrator who lets too much time pass between rotations.
IAM is powerful, but many of its features are frequently ignored.

All credentials, passwords, and API Access Keys should be rotated frequently so that in the event of compromise the stolen keys are valid only for a short, fixed time frame, thereby decreasing attacker access to your instances.

Administrators should set up policies to regularly expire passwords and prevent password reuse across instances. “If an attacker is able to steal your keys, they can then access the resources in your account as if they were you. Use roles whenever possible,” Nunnikhoven says. Mistake 7: Not taking root seriously It pops up time and again.

Admins forget to disable Root API access -- a highly risky practice. No one should be using the AWS root account and associated keys, let alone sharing them across users and applications. Keys to access AWS resources directly should be used sparingly, as the keys need to be tracked, managed, and protected.
In cases where root is absolutely necessary, Saviynt found that those accounts often have multifactor authentication disabled.

The root account deserves better protection than that. Mistake 8: Putting everything in one VPC or account The more teams and workloads added to an account or Virtual Private Cloud (VPC), the more likely you are to meet the lowest common denominator.

AWS has very generous limits on VPCs and accounts.

There's no reason not to isolate workloads and teams into different regions, VPCs, or even accounts.

The simplest way to start is to make sure that development, testing, and production are in different accounts. Mistake 9: Leaving wide open connections Too many admins enable global permissions to instances. When you use 0.0.0.0/0, you are giving every machine everywhere the ability to connect to your AWS resources. “You wouldn't leave the front door to your house open, why do you use 0.0.0.0/0?” Robel asks. AWS Security Groups wrap around EC2 instances to permit or deny inbound and outbound traffic.
It’s tempting -- and expedient! -- to add broad access rules to security rules.

Fight the urge.

Give your security groups the narrowest focus possible. Use different AWS security groups as a source or destination to ensure only instances and load balancers in a specific group can communicate with another group. One-third of the top 30 common AWS configuration mistakes identified by Saviynt involve open ports. Workloads showed open RDP, MySQL, FTP, or telnet ports via Security Groups, and Security Groups showed open RDP and SSH ports. Others were wide open to the internet. Thanks to high-quality automation tools such as OpsWorks, Chef, Ansible, and Puppet, there’s no reason to allow remote access -- such as SSH or RDP -- to EC2 instances.
If an application or OS needs to be patched, it’s better to create a new image and spin up a brand-new instance with the patched applied instead of trying to connect to the instance and applying a patch in place. If remote access is necessary, a “bastion host,” where users connect to an intermediary EC2 instance, is a safer option.
It is easier to manage all remote access connections going to a single host, then restrict what connections are possible between each instance.
It’s also possible to lock down the bastion host so that only pre-approved systems are allowed access.

Control all remote access in order to reduce your overall risk. Mistake 10: Skimping on encryption Many organizations don’t enable encryption in their AWS infrastructures, and the reasons vary from it's too hard to not realizing it was important.
Saviynt found that Relational Database Service (RDS) instances were being created with encryption disabled -- a potential data breach waiting to happen.
In EC2, there were workloads with unencrypted Elastic Block Storage (EBS). Data in S3 should be protected, and traffic between EC2 instances should be secured.
Implementing encryption incorrectly is equally as bad -- if not worse -- than not having encryption at all, but Amazon actually offers tools to help ease the challenges.

Administrators reluctant to enable encryption over concerns of managing keys should let AWS manage those keys.
It’s always possible to migrate to the organization’s own public key infrastructure afterward. Mistakes, not vulnerabilities The fact that privileged users can bring down a whole AWS environment, with critical applications and sensitive information, isn’t the fault of the cloud.
It highlights the fact that for many organizations the security implementation is weak.

Administrators need to apply the same rigorous controls they have had in their datacenters to their cloud infrastructures. Many of these configuration mistakes are not difficult to fix, and they mitigate a large range of potential issues, freeing up administrators to handle more in-depth tasks, such as running a vulnerability scanner like Amazon Inspector or Tenable Network Security’s Nessus.

But first things first, and that means bringing security hygiene to the cloud. Related articles
The ​OpenSSL project has published a set of security advisories for vulnerabilities resolved in the OpenSSL library in December 2015, March, May, June, August and September 2016.

The following is a summary of these vulnerabilities and their status with respect to Juniper products: CVE OpenSSL Severity Rating Summary CVE-2016-6309 Critical statem/statem.c in OpenSSL 1.1.0a does not consider memory-block movement after a realloc call, which allows remote attackers to cause a denial of service (use-after-free) or possibly execute arbitrary code via a crafted TLS session. CVE-2016-0701 High The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 1.0.2f does not ensure that prime numbers are appropriate for Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers to discover a private DH exponent by making multiple handshakes with a peer that chose an inappropriate number, as demonstrated by a number in an X9.42 file. CVE-2016-0703 High The get_client_master_key function in s2_srvr.c in the SSLv2 implementation in OpenSSL before 0.9.8zf, 1.0.0 before 1.0.0r, 1.0.1 before 1.0.1m, and 1.0.2 before 1.0.2a accepts a nonzero CLIENT-MASTER-KEY CLEAR-KEY-LENGTH value for an arbitrary cipher, which allows man-in-the-middle attackers to determine the MASTER-KEY value and decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, a related issue to CVE-2016-0800. CVE-2016-0800 High The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to send a ServerVerify message before establishing that a client possesses certain plaintext RSA data, which makes it easier for remote attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, aka a "DROWN" attack. CVE-2016-2107 High The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC session, NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-0169. CVE-2016-2108 High The ASN.1 implementation in OpenSSL before 1.0.1o and 1.0.2 before 1.0.2c allows remote attackers to execute arbitrary code or cause a denial of service (buffer underflow and memory corruption) via an ANY field in crafted serialized data, aka the "negative zero" issue. CVE-2016-6304 High Multiple memory leaks in t1_lib.c in OpenSSL before 1.0.1u, 1.0.2 before 1.0.2i, and 1.1.0 before 1.1.0a allow remote attackers to cause a denial of service (memory consumption) via large OCSP Status Request extensions. CVE-2015-3193 Moderate The Montgomery squaring implementation in crypto/bn/asm/x86_64-mont5.pl in OpenSSL 1.0.2 before 1.0.2e on the x86_64 platform, as used by the BN_mod_exp function, mishandles carry propagation and produces incorrect output, which makes it easier for remote attackers to obtain sensitive private-key information via an attack against use of a (1) Diffie-Hellman (DH) or (2) Diffie-Hellman Ephemeral (DHE) ciphersuite. CVE-2015-3194 Moderate crypto/rsa/rsa_ameth.c in OpenSSL 1.0.1 before 1.0.1q and 1.0.2 before 1.0.2e allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an RSA PSS ASN.1 signature that lacks a mask generation function parameter. CVE-2015-3195 Moderate The ASN1_TFLG_COMBINE implementation in crypto/asn1/tasn_dec.c in OpenSSL before 0.9.8zh, 1.0.0 before 1.0.0t, 1.0.1 before 1.0.1q, and 1.0.2 before 1.0.2e mishandles errors caused by malformed X509_ATTRIBUTE data, which allows remote attackers to obtain sensitive information from process memory by triggering a decoding failure in a PKCS#7 or CMS application. CVE-2016-0704 Moderate An oracle protection mechanism in the get_client_master_key function in s2_srvr.c in the SSLv2 implementation in OpenSSL before 0.9.8zf, 1.0.0 before 1.0.0r, 1.0.1 before 1.0.1m, and 1.0.2 before 1.0.2a overwrites incorrect MASTER-KEY bytes during use of export cipher suites, which makes it easier for remote attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, a related issue to CVE-2016-0800. CVE-2016-6305 Moderate The ssl3_read_bytes function in record/rec_layer_s3.c in OpenSSL 1.1.0 before 1.1.0a allows remote attackers to cause a denial of service (infinite loop) by triggering a zero-length record in an SSL_peek call. CVE-2016-7052 Moderate crypto/x509/x509_vfy.c in OpenSSL 1.0.2i allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) by triggering a CRL operation. CVE-2015-1794 Low The ssl3_get_key_exchange function in ssl/s3_clnt.c in OpenSSL 1.0.2 before 1.0.2e allows remote servers to cause a denial of service (segmentation fault) via a zero p value in an anonymous Diffie-Hellman (DH) ServerKeyExchange message. CVE-2015-3196 Low ssl/s3_clnt.c in OpenSSL 1.0.0 before 1.0.0t, 1.0.1 before 1.0.1p, and 1.0.2 before 1.0.2d, when used for a multi-threaded client, writes the PSK identity hint to an incorrect data structure, which allows remote servers to cause a denial of service (race condition and double free) via a crafted ServerKeyExchange message. CVE-2015-3197 Low ssl/s2_srvr.c in OpenSSL 1.0.1 before 1.0.1r and 1.0.2 before 1.0.2f does not prevent use of disabled ciphers, which makes it easier for man-in-the-middle attackers to defeat cryptographic protection mechanisms by performing computations on SSLv2 traffic, related to the get_client_master_key and get_client_hello functions. CVE-2016-0702 Low The MOD_EXP_CTIME_COPY_FROM_PREBUF function in crypto/bn/bn_exp.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g does not properly consider cache-bank access times during modular exponentiation, which makes it easier for local users to discover RSA keys by running a crafted application on the same Intel Sandy Bridge CPU core as a victim and leveraging cache-bank conflicts, aka a "CacheBleed" attack. CVE-2016-0705 Low Double free vulnerability in the dsa_priv_decode function in crypto/dsa/dsa_ameth.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via a malformed DSA private key. CVE-2016-0797 Low Multiple integer overflows in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g allow remote attackers to cause a denial of service (heap memory corruption or NULL pointer dereference) or possibly have unspecified other impact via a long digit string that is mishandled by the (1) BN_dec2bn or (2) BN_hex2bn function, related to crypto/bn/bn.h and crypto/bn/bn_print.c. CVE-2016-0798 Low Memory leak in the SRP_VBASE_get_by_user implementation in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g allows remote attackers to cause a denial of service (memory consumption) by providing an invalid username in a connection attempt, related to apps/s_server.c and crypto/srp/srp_vfy.c. CVE-2016-0799 Low The fmtstr function in crypto/bio/b_print.c in OpenSSL 1.0.1 before 1.0.1s and 1.0.2 before 1.0.2g improperly calculates string lengths, which allows remote attackers to cause a denial of service (overflow and out-of-bounds read) or possibly have unspecified other impact via a long string, as demonstrated by a large amount of ASN.1 data, a different vulnerability than CVE-2016-2842. CVE-2016-2105 Low Integer overflow in the EVP_EncodeUpdate function in crypto/evp/encode.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to cause a denial of service (heap memory corruption) via a large amount of binary data. CVE-2016-2106 Low Integer overflow in the EVP_EncryptUpdate function in crypto/evp/evp_enc.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to cause a denial of service (heap memory corruption) via a large amount of data. CVE-2016-2109 Low The asn1_d2i_read_bio function in crypto/asn1/a_d2i_fp.c in the ASN.1 BIO implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to cause a denial of service (memory consumption) via a short invalid encoding. CVE-2016-2176 Low The X509_NAME_oneline function in crypto/x509/x509_obj.c in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h allows remote attackers to obtain sensitive information from process stack memory or cause a denial of service (buffer over-read) via crafted EBCDIC ASN.1 data. CVE-2016-2182 Low The BN_bn2dec function in crypto/bn/bn_print.c in OpenSSL before 1.1.0 does not properly validate division results, which allows remote attackers to cause a denial of service (out-of-bounds write and application crash) or possibly have unspecified other impact via unknown vectors. CVE-2016-6303 Low Integer overflow in the MDC2_Update function in crypto/mdc2/mdc2dgst.c in OpenSSL before 1.1.0 allows remote attackers to cause a denial of service (out-of-bounds write and application crash) or possibly have unspecified other impact via unknown vectors. CVE-2016-2179 Low The DTLS implementation in OpenSSL before 1.1.0 does not properly restrict the lifetime of queue entries associated with unused out-of-order messages, which allows remote attackers to cause a denial of service (memory consumption) by maintaining many crafted DTLS sessions simultaneously, related to d1_lib.c, statem_dtls.c, statem_lib.c, and statem_srvr.c. CVE-2016-2180 Low The TS_OBJ_print_bio function in crypto/ts/ts_lib.c in the X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) implementation in OpenSSL through 1.0.2h allows remote attackers to cause a denial of service (out-of-bounds read and application crash) via a crafted time-stamp file that is mishandled by the "openssl ts" command. CVE-2016-2181 Low The Anti-Replay feature in the DTLS implementation in OpenSSL before 1.1.0 mishandles early use of a new epoch number in conjunction with a large sequence number, which allows remote attackers to cause a denial of service (false-positive packet drops) via spoofed DTLS records, related to rec_layer_d1.c and ssl3_record.c. CVE-2016-6302 Low The tls_decrypt_ticket function in ssl/t1_lib.c in OpenSSL before 1.1.0 does not consider the HMAC size during validation of the ticket length, which allows remote attackers to cause a denial of service via a ticket that is too short. CVE-2016-2177 Low OpenSSL through 1.0.2h incorrectly uses pointer arithmetic for heap-buffer boundary checks, which might allow remote attackers to cause a denial of service (integer overflow and application crash) or possibly have unspecified other impact by leveraging unexpected malloc behavior, related to s3_srvr.c, ssl_sess.c, and t1_lib.c. CVE-2016-2178 Low The dsa_sign_setup function in crypto/dsa/dsa_ossl.c in OpenSSL through 1.0.2h does not properly ensure the use of constant-time operations, which makes it easier for local users to discover a DSA private key via a timing side-channel attack. CVE-2016-6306 Low The certificate parser in OpenSSL before 1.0.1u and 1.0.2 before 1.0.2i might allow remote attackers to cause a denial of service (out-of-bounds read) via crafted certificate operations, related to s3_clnt.c and s3_srvr.c. CVE-2016-6307 Low The state-machine implementation in OpenSSL 1.1.0 before 1.1.0a allocates memory before checking for an excessive length, which might allow remote attackers to cause a denial of service (memory consumption) via crafted TLS messages, related to statem/statem.c and statem/statem_lib.c. CVE-2016-6308 Low statem/statem_dtls.c in the DTLS implementation in OpenSSL 1.1.0 before 1.1.0a allocates memory before checking for an excessive length, which might allow remote attackers to cause a denial of service (memory consumption) via crafted DTLS messages. CVE-2016-2176 is a vulnerability that only affects EBCDIC systems. No Juniper products are affected by this vulnerability. Affected Products: Junos OS: Junos OS is potentially affected by many of these issues. Junos OS is not affected by CVE-2016-0701, CVE-2016-0800, CVE-2016-2107, CVE-2016-2176, CVE-2016-2179, CVE-2016-2181, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. ScreenOS: ScreenOS is potentially affected by many of these issues.
ScreenOS is not affected by CVE-2015-1794, CVE-2015-3193, CVE-2015-3194, CVE-2015-3196, CVE-2015-3197, CVE-2016-0701, CVE-2016-2107, CVE-2016-2109, CVE-2016-2179, CVE-2016-2181, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. Junos Space: Junos Space is potentially affected by many of these issues. Junos Space is not affected by CVE-2015-1794, CVE-2016-0705, CVE-2016-0798, CVE-2016-2176, CVE-2015-3193, CVE-2015-3196, CVE-2016-0701, CVE-2016-2107, CVE-2016-6305, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. NSM: NSM is potentially affected by many of these issues. NSM is not affected by CVE-2015-1794, CVE-2016-0705, CVE-2016-0798, CVE-2016-2176, CVE-2015-3193, CVE-2015-3196, CVE-2016-0701, CVE-2016-2107, CVE-2016-6305, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. Juniper Secure Analytics (JSA, STRM): STRM, JSA series is potentially affected by these issues. CTPView/CTPOS: CTPView and CTPOS are potentially affected by many these issues.

CTPView and CTPOS are not affected by CVE-2015-1794, CVE-2016-0705, CVE-2016-0798, CVE-2016-2176, CVE-2015-3193, CVE-2015-3196, CVE-2016-0701, CVE-2016-2107, CVE-2016-6305, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309 and CVE-2016-7052. Junos OS: OpenSSL December 2015 advisory: CVE-2015-3193, CVE-2015-3194, CVE-2015-3195, CVE-2015-3196 and CVE-2015-1794 are resolved in 12.1X44-D60, 12.1X46-D45, 12.1X46-D51, 12.1X47-D35, 12.3R12, 12.3R13, 12.3X48-D25, 13.2X51-D40, 13.3R9, 14.1R7, 14.1X53-D35, 14.2R6, 15.1F5, 15.1R3, 15.1X49-D40, 15.1X53-D35, 16.1R1 and all subsequent releases (PR 1144520). OpenSSL March 2016 advisory: CVE-2016-0705, CVE-2016-0798, CVE-2016-0797, CVE-2016-0799, CVE-2016-0702, CVE-2016-0703 and CVE-2016-0704 are resolved in 13.3R10*, 14.1R8, 14.1X53-D40*, 14.2R7, 15.1F5-S4, 15.1F6, 15.1R4, 15.1X49-D60, 15.1X53-D50, 16.1R1 and all subsequent releases (PR 1165523, 1165570). OpenSSL May 2016 advisory: CVE-2016-2105, CVE-2016-2106, CVE-2016-2108, CVE-2016-2109, CVE-2016-2176, CVE-2016-2180 are resolved in 13.3R10*, 14.1R9*, 14.1X53-D40*, 14.2R8*, 15.1F5-S4, 15.1F6-S2, 15.1R4, 15.1X53-D50, 15.1X53-D60, 16.1R1 and all subsequent releases.

Fixes are in progress for other supported Junos releases (PR 1180391). OpenSSL June to September 2016 advisories: CVE-2016-2177, CVE-2016-2178, CVE-2016-2179, CVE-2016-2180, CVE-2016-2181, CVE-2016-2182, CVE-2016-6302, CVE-2016-6303, CVE-2016-6304, CVE-2016-6305, CVE-2016-6306, CVE-2016-6307, CVE-2016-6308, CVE-2016-6309, CVE-2016-7052 are resolved in 13.3R10*, 14.1R9*, 14.2R8*, 15.1R5*, 16.1R4* and all subsequent releases.

Fixes are in progress for other supported Junos releases (PR 1216923). CVE-2016-2108 was resolved when fixes for OpenSSL Advisories in June and July 2015 were implemented in Junos.

At that time OpenSSL version was upgraded to 1.0.1p in Junos 13.3 and later releases which included a fix for this issue. Please see JSA10694​ for solution releases. Note: * - These Junos releases are pending release at the time of publication. Note: While Junos is not affected or impacted by certain CVEs, fixes for those get included with the relevant OpenSSL version upgrade. Hence these are stated as resolved. ScreenOS: CVE-2015-3195 is resolved in 6.3.0r22.

This issue is being tracked as PR 1144749. Please see JSA10733 further details. Rest of the applicable issues in OpenSSL advisories until May 2016 in have been resolved in ScreenOS 6.3.0r23.

These issues are being tracked as PRs 1180504 and 1165796. Fixes for issues in OpenSSL advisories from June to September are being tracked as PR 1217005. Junos Space: OpenSSL software has been upgraded to 1.0.1t in Junos Space 16.1R1 (pending release) to resolve all the issues included in OpenSSL advisories until May 2016.

These issues are being tracked as PRs 1144741, 1158268, 1165853, 1180505, 1212590. Fixes for issues in OpenSSL advisories from June to September are being tracked as PR 1216998. NSM: OpenSSL software has been upgraded to 1.0.2h in NSM 2012.2R13 to resolve all the issues included in OpenSSL advisories until May 2016.

This upgrade is being tracked as PR 1198397. Fixes for issues in OpenSSL advisories from June to September are being tracked as PR 1217003. Juniper Secure Analytics (JSA, STRM): OpenSSL December 2015 and March 2016 advisories: CVE-2015-3194, CVE-2015-3195, CVE-2015-3196, CVE-2015-1794, CVE-2015-3193, CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0705, CVE-2016-0797, CVE-2016-0798, CVE-2016-0799 and CVE-2016-0800 have been resolved in 2014.6.R4.A resolution for other issues is pending release.These issues are being tracked as PR 1151137, 1165861. CTPView CVE-2015-3194 and CVE-2015-3195 have been resolved in 7.1R3, 7.2R1 and all subsequent releases (PR 1144746). CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0797, CVE-2016-0799 and CVE-2016-0800 have been resolved in 7.1R3, 7.2R2, 7.3R1 and all subsequent releases (PR 1165849). CTPOS CVE-2015-3194 and CVE-2015-3195 have been resolved in 7.2R1 and all subsequent releases (PR 1144964). CVE-2016-0702, CVE-2016-0703, CVE-2016-0704, CVE-2016-0797, CVE-2016-0799 and CVE-2016-0800 have been resolved in 7.0R7, 7.1R3, 7.2R2, 7.3R1 and all subsequent releases (PR 1165847). Standard security best current practices (control plane firewall filters, edge filtering, access lists, etc.) may protect against any remote malicious attacks. Junos OS Since SSL is used for remote network configuration and management applications such as J-Web and SSL Service for JUNOScript (XNM-SSL), viable workarounds for this issue in Junos may include: Disabling J-Web Disable SSL service for JUNOScript and only use Netconf, which makes use of SSH, to make configuration changes Limit access to J-Web and XNM-SSL from only trusted networks ScreenOS Methods to reduce the risk associated with this issue include: Limit access to SSL ports to only trusted hosts. Disabling web administrative services will mitigate the risk of this issue:unset int eth0/0 manage web Refer to KB6713 for enabling SSH on the firewall. General Mitigation It is good security practice to limit the exploitable attack surface of critical infrastructure networking equipment. Use access lists or firewall filters to limit access to the HTTPS or SSL/TLS services only from trusted, administrative networks or hosts.
Thales and Ponemon Institute research confirms organisations’ biggest PKI challenge is inability of existing infrastructure to support new applicationsPlantation, FL – 11 October 2016 – Thales, leader in critical information systems, cyber security and data protection, announces the results of its 2016 PKI Global Trends Study.

The report, based on independent research by the Ponemon Institute and sponsored by Thales, reveals an increased reliance on public key infrastructures (PKIs) in today’s enterprise environment, driven by the growing use of cloud-based services and applications and the Internet of Things (IoT). More than 5000 business and IT managers were surveyed in 11 countries: US, UK, Germany, France, Australia, Japan, Brazil, the Russian Federation, Mexico, India, and for the first time this year the Middle East (Saudi Arabia and United Arab Emirates), with the aim of better understanding the use of PKI within organisations. News facts: 62% of businesses regard cloud-based services as the most important trend driving the deployment of applications using PKI (50% in 2015) and over a quarter (28%) say IoT will drive this deployment PKIs are increasingly used to support more and more applications. On average they support eight different applications within a business – up one from 2015, but in the United States this number went up by three applications The most significant challenge organisations face around PKI is the inability of their existing PKIs to support new applications (58% of respondents said this) Worryingly, a large percentage of respondents continue to report that they have no certificate revocation techniques The use of high assurance mechanisms such as hardware security modules (HSMs) to secure PKI has increased The top places where HSMs are deployed to secure PKIs are for the most critical root and issuing certificate authority (CA) private keys together with offline and online root certificate authorities Dr. Larry Ponemon, chairman and founder of The Ponemon Institute, says:As organisations digitally transform their business, they are increasingly relying on cloud-based services and applications, as well as experiencing an explosion in IoT connected devices.

This rapidly escalating burden of data sharing and device authentication is set to apply an unprecedented level of pressure onto existing PKIs, which now are considered part of the core IT backbone, resulting in a huge challenge for security professionals to create trusted environments.
In short, as organisations continue to move to the cloud it is hugely important that PKIs are future proofed – sooner rather than later.” John Grimm, senior director security strategy, Thales e-Security, says:“An increasing number of today’s enterprise applications are in need of digital certificate issuance services — and many PKIs are not equipped to support them.

A PKI needs a strong root of trust to be fit for purpose if it is to support the growing dependency and business criticality of its services.

By securing the process of issuing certificates and managing signing keys in an HSM, organisations can greatly reduce the risk of their loss or theft, thereby creating a high assurance foundation for digital security.

Thales has decades of experience providing HSM-based PKI solutions and services that help organisations deploy world-class PKIs and trusted infrastructures.” Download your copy of the new 2016 PKI Global Trends Study: http://go.thales-esecurity.com/2016GlobalPKITrends For industry insight and views on the latest key management trends check out our blog www.thales-esecurity.com/blogs Follow Thales e-Security on Twitter @Thalesesecurity, LinkedIn, Facebook and YouTube About Thales e-SecurityThales e-Security + Vormetric have combined to form the leading global data protection and digital trust management company.

Together, we enable companies to compete confidently and quickly by securing data at-rest, in-motion, and in-use to effectively deliver secure and compliant solutions with the highest levels of management, speed and trust across physical, virtual, and cloud environments.

By deploying our leading solutions and services, targeted attacks are thwarted and sensitive data risk exposure is reduced with the least business disruption and at the lowest life cycle cost.

Thales e-Security and Vormetric are part of Thales Group. www.thales-esecurity.com About ThalesThales is a global technology leader for the Aerospace, Transport, Defence and Security markets. With 62,000 employees in 56 countries, Thales reported sales of €14 billion in 2015. With over 22,000 engineers and researchers, Thales has a unique capability to design and deploy equipment, systems and services to meet the most complex security requirements.
Its exceptional international footprint allows it to work closely with its customers all over the world. Positioned as a value-added systems integrator, equipment supplier and service provider, Thales is one of Europe’s leading players in the security market.

Thales solutions secure the four key domains considered vital to modern societies: government, cities, critical infrastructure and cyberspace. Drawing on renowned cryptographic capabilities, Thales is one of the world leaders in cybersecurity products and solutions for defense, governmental bodies, critical infrastructures operators, communication, industrial and financial companies. With a presence throughout the information security chain, Thales offers a comprehensive range of services and solutions ranging from security consulting and audits, data protection, digital trust management, cybersecured sytem design, development, integration, certification and through-life management to cyber-threat intelligence, intrusion detection and security supervision with Security Operation Centres in France, the United Kingdom, The Netherlands and soon in Hong Kong. Press contactsThales, Media Relations SecurityDorothée Bonneil+33 (0)6 84 79 65 86dorothee.bonneil@thalesgroup.com Thales, Media Relations e-SecurityLiz Harris+44 (0)7973 903648liz.harris@thales-esecurity.com

Folder Lock

By now it should be clear that encryption isn't just for security geeks and IT administrators. You can take precautions to secure your own most sensitive files and folders by encrypting them.
Some encryption utilities turn files and folders into encoded versions of themselves. Others create secure storage locations that act like standard drives or folders but can be locked, encrypting all of their contents.
Still others maintain encrypted storage in the cloud. Most encryption utilities stick to just one of these functions.

Folder Lock does all three things, and more, balancing ease of use with a wide range of features. As with most competing products, your $39.95 purchase entitles you to use Folder Lock 7.6 (the version I tested) indefinitely. You don't have to buy right away; you can run the program 25 times before it demands payment. You also get free access to all updates until the next major point update. When version 8 comes out, you can either pay an update fee or just keep using the current version. What Is Encryption?The Nazi government used a device called the Enigma Machine to encrypt sensitive military communications before and during World War II. With its rows of buttons and actuator wheels, the device looked quite impressive. However, not only did the Allied forces crack the code, they managed to keep that fact from the enemy, so the Nazi generals kept sharing their strategies using the faulty encryption system.

The resulting intelligence served the Allied forces well. Cryptographic algorithms used today have a certain connection to the old Enigma Machine, but of course they're totally code-based, with no steampunk buttons or wheels. Unless you have the password, there's no way to decrypt an encrypted document. No, you can't just try every possible password, not unless you're willing to wait for the heat death of the universe. In 2001, the US government settled on Advanced Encryption Standard (AES). as its official algorithm, replacing the less-secure Data Encryption Standard. With even more bits in its main security key, Bruce Schneier's Blowfish algorithm should be still more secure. You're probably familiar with symmetric encryption algorithms, where the same key encrypts and decrypts a file.

AES, Blowfish, and many other common algorithms are symmetric. With this kind of algorithm, you must keep the password a deep, dark secret, and only share it via secure channels.

But there's another way.
In a Public Key Infrastructure system, you get two keys, one public and one private.
If I want to send you a file, I look up your public key and use it for encryption; you decrypt it with your private key. Public key cryptography is less common in small-scale encryption utilities. Getting Started With Folder LockInstallation of the product is quick and simple When you do pay up, you'll receive a serial number and a registration key. Keep that serial number stored in a safe place.
If you forget your master password, you can unlock the program by entering that serial number. If that last statement worries you, congratulations—you've caught on to something.

All of the encryption products I've reviewed recently have no backdoor, no way for the company to decrypt your files.

But since the company clearly has your Folder Lock serial number, it could conceivably be ordered to supply it to law enforcement. You can disable this feature in settings, and I strongly suggest that you do so. Like AxCrypt Premium, Folder Lock relies on a master password. Once you've logged in with the master password, you're free to lock and unlock files, folders, and drives without having to enter it again. Of course this should be a strong, memorable password, something that you can remember but that nobody else would guess. There is an Auto Protection option, disabled by default.
If you turn this feature on, it shuts down the program after 10 minutes of inactivity. You can set the timeout from one to 100 minutes, and you can configure it to log out of Windows, or shut down Windows, rather than just shut down the program. If you're concerned someone might try to break into your Folder Lock installation, you can enable Hack Security.

At its default settings, this feature shuts down Folder Lock after three incorrect login attempts.
If you frequently fumble-finger your password, you may want to set a higher number. You can also configure it to log out of your Windows account or even shut down Windows altogether after a number of failed attempts. Locking and UnlockingSo, what does it mean to lock a file or folder? A locked file is not encrypted.
Instead, Folder Lock uses a technique called kernel level filtering to hide the locked file from Windows, and from all programs running under Windows.
If that sounds a bit like the way a rootkit hides its components from Windows, well, it is quite similar, but working for good, not evil. Locked files are protected from casual snooping, which may be all you need. To lock a file or folder, you just drop it on Folder Lock.
It appears inside Folder Lock and vanishes from Windows Explorer.

The locking process happens in a flash, faster than encryption. You can also use a menu within the program to lock files, folders, and drives. Of course, you can't lock the Windows drive. The Lock Folders page in the program's main window lists all of your locked items, with a green padlock next to each.
If you're done locking one or more items, you select them and click the button Unlock Items, or right-click and choose Remove. When you do so, the item vanishes from Folder Lock and reappears in Windows Explorer. It's more likely that you'll simply want to access a locked item while keeping it secure.

Clicking Protection Off leaves the item inside Folder Lock, with a red open padlock icon replacing the green locked padlock.

The item reappears in Windows Explorer so you can access it. You can configure Folder Lock so that when it shuts down, it turns protection back on automatically.
In use, it feels somewhat similar to AxCrypt's Secured Folders feature. Folder Lock doesn't just hide files and folders.
It can actually hide itself as well. Just engage Stealth Mode and anybody snooping around your computer won't see a trace of it.

To bring it out of hiding, you press the hotkey combination that you selected when invoking Stealth Mode.
Security experts turn up their noses at security through obscurity, but this feature really can help fend off casual snoops. Encrypted LockersLocking items makes them invisible, but a determined hacker with physical access to the computer could conceivably still get at the data, perhaps by booting to a non-Windows environment.

For serious file protection, you need to create one or more encrypted lockers.

These correspond to vaults in InterCrypto CryptoExpert 8 and to encrypted volumes in Cypherix PE. You start by naming your locker and accepting (or changing) the location for the file that holds the locker's data. Next you set a password to protect the locker's contents. Like InterCrypto Advanced Encryption Package 2016, Folder Lock includes a virtual keyboard to eliminate any possibility of password capture by a keylogger.
It rates password strength as you type, but unlike AxCrypt it's pretty forgiving.
It accepted "Password1" as strong password. Next you must choose whether to create a backup-able FAT32 locker, accepting the limitation that no file larger than 4GB can be stored, or go for the no-limits NTFS format. You also set a maximum size.

The initial size on disk is much smaller, growing as needed up to that maximum.

Folder Lock takes care of formatting the drive, whichever file system you use.

Cypherix PE, by contrast, relies on Windows to format NTFS virtual drives. By default, Folder Lock assigns drive letters starting with Z: and works down from there. When you open a locker, you can choose a specific drive letter, and optionally open the locker in read-only mode.
I did not, however, find a way to permanently assign a specific drive letter to a locker, the way Cypherix and CryptoExpert permit.
If you try to close a locker that contains open files, the program warns you to close those files first. Folder lock uses government-standard AES 256-bit encryption, and it claims to have the fastest AES algorithm around.

That should be fine for most users. Yes, Advanced Encryption Package offers a choice of 17 different algorithms, and Ranquel Technologies CryptoForge lets you apply any or all of its four algorithms simultaneously, but most users don't have the crypto-expertise to pick an algorithm. Shred FilesThere's no point in copying an encrypted file into secure storage if you leave the plaintext original lying around.
In addition, just deleting the file isn't sufficient to wipe out its data.

Forensic recovery software can often get back deleted files in their entirety.

Folder Lock's file shredder securely deletes files so they can't be recovered. The Shred Files page gives the appearance of a drag-drop target, but it isn't. You must browse and select items to shred.

Folder Lock also lacks the context menu integration found in Cypherix SecureIT, Ranquel Technologies CryptoForge, and others. By default, Folder Lock simply overwrites the file or folder with zeroes. You can set it to overwrite with random bytes instead.
If you're willing to have the shredder run a bit slower in order to more thoroughly erase the data, you can choose the three-pass Department of Defense algorithm, or the 35-pass Gutmann algorithm.

But unless you anticipate law enforcement spending huge amounts of time and effort to recover your sinister deleted files, the single pass with zeroes or random numbers is probably sufficient.
If shredding algorithms fascinate you, check out the 18 distinct algorithms in InterCrypto Advanced Encryption Package 2016, most of which are government sanctioned. By default, Folder Lock won't shred any lockers, locked files, or wallets (more about wallets in a bit).

That makes sense to me.

But if you think otherwise, you can turn off this precautionary setting. Here's a handy feature; Folder Lock includes the ability to overwrite all the free space on your drives.

Doing so effectively applies secure deletion to all the files you've deleted previously.

Be warned, this can take a very long time, especially if you select one of the multi-pass shredding algorithms. Secure BackupCertainSafe Digital Safety Deposit Box stores your encrypted files directly to multiple encrypted cloud servers, ensuring security by splitting up parts of the file to different servers.

Folder Lock doesn't do that, but it offers secure backup for your encrypted lockers. The secure backup component requires a subscription, separate from the price of Folder Lock. Rates range from $5 per month for 10GB, through $30 per month for 100GB, all the way up to $400 per month for 2TB.

A free one-month trial is available for plans up to 100GB. Once you've logged in to your secure backup account, you can configure automatic backup for any locker that you defined as backup-able during its creation.

The already-encrypted locker data is transmitted via a secure SSL connection. You can optionally choose to sync a locker between multiple PCs that have Folder Lock installed. USB and Email ProtectionCypherix SecureIT and Advanced Encryption Package can turn encrypted files into self-decrypting executables, files that don't require the program itself for decryption.
In an interesting twist, Folder Lock lets you make entire lockers into self-decrypting files that you can store on USB drives or even on DVDs. You can either make a self-decrypting copy of an existing locker or create a new locker directly on the removable drive. From the USB Protection page, you can also encrypt files to send as email attachments.

Folder Lock creates an encrypted ZIP file with the name, location, and password of your choice.
It then launches your email client to send that ZIP file as an attachment. What's in Your Wallet?Sometimes the information you want to store securely isn't in the form of a file. You could create a file containing, say, the details that define your bank account and then encrypt it.

But it's easier to just put that data in a wallet. Creating a new wallet is simple.

All you do is indicate the name and location for the file that represents the wallet and enter a password.

As with locker creation, Folder Lock rates password strength as you type. Now you can put virtual cards in the wallet.

First, you name the card and select a type: bank account, business card, business info, credit card, general purpose, health and hygiene, ID card, license, and passport.

The next screen contains data fields relevant to the type you chose. Like the secure online password storage offered by AxCrypt, this is strictly a static data dump.
If you want to make use of the stored information, say, to fill a Web form, you'll have to copy and paste. You can, if you wish, create multiple wallets for different purposes. History CleanerThe point of encrypting your data is to ensure it can't be accessed by anyone but you. However, in the process of editing documents, visiting websites, and so on, you create a trail of evidence.

Temporary files, browsing history, cached webpages, all of these have the potential to compromise your security.

Folder Lock's Clean History feature aims to help by wiping out at least some of these traces. It wipes out Windows temporary files, clears the clipboard, and deletes the system's memory of what folder you last used when opening or saving files.
It clears recently used file history from Media Player, WordPad, and the Paint app.

And it clears a number of Windows recently used file lists. This isn't remotely the full system cleanup you get from a purpose-built tune-up utility.
It doesn't wipe browser traces, or recently used lists from third-party utilities. On the plus side, it runs in an instant. A Well-Balanced UtilityFolder Lock packs a ton of useful encryption-related features into a bright and cheerful package that's easy to navigate. While not as technically deep, it actually offers more encryption options than InterCrypto Advanced Encryption Package, which suffers from an awkward, dated interface.
Its interface is modern, like that of AxCrypt, but its range of encryption styles is greater than AxCrypt's. This fine balance between ease of use and breadth of features earns Folder Lock our Editors' Choice award for encryption.
It shares that honor with two quite different products, AxCrypt Premium and CertainSafe Digital Safety Deposit Box. Back to top PCMag may earn affiliate commissions from the shopping links included on this page.

These commissions do not affect how we test, rate or review products.

To find out more, read our complete terms of use.
Businesses, websites, and government agencies that store your personal data have a duty to protect that data from hackers. Not that even the best practices and security software can keep the hackers out—they always find a way in.

But if the data is properly encrypted, stealing it doesn't do the hacker much good. You can up your security game by encrypting sensitive data on your own desktop and laptop computers. We've rounded up a collection of products to help you with that project.

This isn't an exhaustive list, and we will update this story with additional products in the future. No Back DoorsWhen the FBI needed information from the San Bernardino shooter's iPhone, they asked Apple for a back door to get past the encryption.

But no such back door existed, and Apple refused to create one.

The FBI had to hire hackers to get into the phone. Why wouldn't Apple help? Because the moment a back door or similar hack exists, it becomes a target, a prize for the bad guys.
It will leak sooner or later.
In a talk at Black Hat, Apple's Ivan Krstic revealed that the company has done something similar in their cryptographic servers. Once the fleet of servers is up and running, they physically destroy the keys that would permit modification.

Apple can't update them, but the bad guys can't get in either. All of the products in this roundup explicitly state that they have no back door, and that's as it should be.
It does mean that if you encrypt an essential document and then forget the encryption password, you've lost it for good. Two Main ApproachesBack in the day, if you wanted to keep a document secret you could use a cipher to encrypt it and then burn the original. Or you could lock it up in a safe.

The two main approaches in encryption utilities parallel these options. One type of product simply processes files and folders, turning them into impenetrable encrypted versions of themselves.

The other creates a virtual disk drive that, when open, acts like any other drive on your system. When you lock the virtual drive, all of the files you put into it are completely inaccessible. Similar to the virtual drive solution, some products store your encrypted data in the cloud.

This approach requires extreme care, obviously.

Encrypted data in the cloud has a much bigger attack surface than encrypted data on your own PC. Which is better? It really depends on how you plan to use encryption.
If you're not sure, take advantage of the 30-day free trial offered by all of these products to get a feel for the different options. Secure Those OriginalsAfter you copy a file into secure storage, or create an encrypted version of it, you absolutely need to wipe the unencrypted original. Just deleting it isn't sufficient, even if you bypass the Recycle Bin, because the data still exists on disk, and data recovery utilities can often get it back. Some encryption products avoid this problem by encrypting the file in place, literally overwriting it on disk with an encrypted version.
It's more common, though, to offer secure deletion as an option.
If you choose a product that lacks this feature, you should find a free secure deletion tool to use along with it. Overwriting data before deletion is sufficient to balk software-based recovery tools. Hardware-based forensic recovery works because the magnetic recording of data on a hard drive isn't actually digital.
It's more of a wave form.
In simple terms, the process involves nulling out the known data and reading around the edges of what's left.
If you really think someone (the feds?) might use this technique to recover your incriminating files, you can set your secure deletion tool to make more passes overwriting the data. Encryption AlgorithmsAn encryption algorithm is like a black box.

Dump a document, image, or other file into it, and you get back what seems like gibberish. Run that gibberish back through the box, with the same password, and you get back the original. The U.S. government has settled on Advanced Encryption Standard (AES) as a standard, and all of the products gathered here support AES.

Even those that support other algorithms tend to recommend using AES. If you're an encryption expert, you may prefer another algorithm, Blowfish, perhaps, or the Soviet government's GOST.

For the average user, however, AES is just fine. Public Key Cryptography and SharingPasswords are important, and you have to keep them secret, right? Well, not when you use Public Key Infrastructure (PKI) cryptography. With PKI, you get two keys. One is public; you can share it with anyone, register it in a key exchange, tattoo it on your forehead—whatever you like.

The other is private, and should be closely guarded.
If I want to send you a secret document, I simply encrypt it with your public key. When you receive it, your private key decrypts it.
Simple! Using this system in reverse, you can create a digital signature that proves your document came from you and hasn't been modified. How? Just encrypt it with your private key.

The fact that your public key decrypts it is all the proof you need. PKI support is less common than support for traditional symmetric algorithms. If you want to share a file with someone and your encryption tool doesn't support PKI, there are other options for sharing. Many products allow creation of a self-decrypting executable file. You may also find that the recipient can use a free, decryption-only tool. What's the Best?Right now there are two Editors' Choice products in the consumer-accessible encryption field. One is the easiest to use of the bunch, the other is the most secure. AxCrypt Premium has a sleek, modern look, and when its active you'll hardly notice it.

Files in its Secured Folders get encrypted automatically when you sign out, and it's one of the few that support public key cryptography. CertainSafe Digital Safety Deposit Box goes through a multi-stage security handshake that authenticates you to the site and authenticates the site to you. Your files are encrypted, split into chunks, and tokenized.

Then each chunk gets stored on a different server.

A hacker who breached one server would get nothing useful. The other products here also have their merits, of course. Read the full reviews and decide which one you'll use to protect your files. Have an opinion on one of the apps reviewed here, or a favorite tool we didn't mention? Let us know in the comments. FEATURED IN THIS ROUNDUP
reader comments 52 Share this story Microsoft has inadvertently demonstrated the intrinsic security problem of including a universal backdoor in its software after it accidentally leaked its so-called "golden key"—which allows users to unlock any device that's supposedly protected by Secure Boot, such as phones and tablets.The key basically allows anyone to bypass the provisions Microsoft has put in place ostensibly to prevent malicious versions of Windows from being installed, on any device running Windows 8.1 and upwards with Secure Boot enabled. And while this means that enterprising users will be able to install any operating system—Linux, for instance—on their Windows tablet, it also allows bad actors with physical access to a machine to install bootkits and rootkits at deep levels. Worse, according to the security researchers who found the keys, this is a decision Microsoft may be unable to reverse. The golden keys were found by MY123 and Slipstream in March this year.

They've just posted, on a rather funky website, a description both of Microsoft's security errors and of its seeming reluctance to patch the issue.

The researchers note that this snafu is a real-world demonstration of the lack of wisdom in the FBI's recent demands for universal backdoors in Apple's devices.

They wrote: A backdoor, which MS put in to Secure Boot because they decided to not let the user turn it off in certain devices, allows for Secure Boot to be disabled everywhere! You can see the irony.

Also the irony in that MS themselves provided us several nice "golden keys" (as the FBI would say) ;) for us to use for that purpose :) About the FBI: are you reading this? If you are, then this is a perfect real world example about why your idea of backdooring cryptosystems with a "secure golden key" is very bad! Smarter people than me have been telling this to you for so long, it seems you have your fingers in your ears. You seriously don't understand still? Microsoft implemented a "secure golden key" system.

And the golden keys got released from MS['s] own stupidity. Now, what happens if you tell everyone to make a "secure golden key" system? Hopefully you can add 2+2... The researchers seem to have found the golden key—which isn't a PKI-type private key you would use to sign binaries, but rather a way to alter the tasks executed by UEFI at boot—bundled in dormant form on retail devices, left in as a debugging tool by accident. Now apparently available online, it should allow any user to turn off Secure Boot. Secure Boot works at the firmware level, and is designed only to allow an operating system signed with a key certified by Microsoft to load.
It can be disabled on many desktops, but on most other Windows devices, it's hard-coded in.

The golden key policy seems to have been designed for internal debugging purposes, to allow OS signature checks to be disabled, apparently so programmers can test new builds.
In practice, it could well open up Microsoft's tablets and phones to serious attacks. At first, Microsoft apparently dismissed the find as a non-issue, before changing its mind, and then slowly applying a patch.

The software giant eventually awarded a bug bounty in June, and has since released two patches—MS16-094 and MS16-100—with a third on the way.
It's understood that none of them are able to directly shut the back door, and there's a distinct possibility that the hole opened by the golden keys may not be truly closable. According to the researchers, "it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc." In February, in the wake of the San Bernardino shootings in the US, the FBI asked Apple to introduce backdoors into its products, after it had proved difficult to access information on an iPhone belonging to one of the shooters.
In a statement, Apple CEO Tim Cook wrote: We have great respect for the professionals at the FBI, and we believe their intentions are good. Up to this point, we have done everything that is both within our power and within the law to help them.

But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create.

They have asked us to build a backdoor to the iPhone. Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation.
In the wrong hands, this software—which does not exist today—would have the potential to unlock any iPhone in someone's physical possession. The FBI may use different words to describe this tool, but make no mistake: Building a version of iOS that bypasses security in this way would undeniably create a backdoor.

And while the government may argue that its use would be limited to this case, there is no way to guarantee such control. Ars has sought comment from Microsoft. This story was updated to clarify the nature of the "golden key," which isn't technically a key at all. This post originated on Ars Technica UK