Tag Archives: Encryption

Encryption, a buzzword, not a silver bullet

Encryption,  buzzword, not a silver bullet for protecting data on your servers.

In order to determine how encryption fits into server data protection, consider 4 encryption components on the server side: passwords, tables, partitions and  inter-tier socket communications.

In these 4 components of a application / database server encryption policy, note that some countermeasures are required (for example one-way hashes of passwords, while other such as encrypting specify table columns may or may not be relevant to a particular application).

1. Encrypted password storage

You must encrypt passwords. It’s surprising to me how many Web sites don’t bother encrypting user passwords – See cases Universal Music Portugal where e-mail addresses and clear-text passwords are dumped on Internet.

What is more surprising is the confusion between encryption and hashing.

Don’t use AES for encrypting passwords in your MySQL or Oracle or MS SQL database.  You’ll end up storing the AES key somewhere in the code and an attacker or malicious insider can read the key by opening up one of your application DLLs in Notepad++ and read that key in a jiffy and breach your entire MySQL database with a single SELECT statement.

Database user passwords should be stored as MD5 hashes, so that a user  (such as a DBA) who has been granted SELECT access to the table (typically called ‘users’)  cannot determine the actual password. Make sure that different instances have different salts and include some additional information in the hash.

If you use MD5 encryption for client authentication, make sure that  the client hashes the password with MD5 before sending the data on the network.

2. Encrypt specific database table columns

The PostgreSQL 9.1 pgcrypto module allows certain fields to be stored encrypted. This is especially useful if some of the data is sensitive for example in the case of ePHI where the Web application needs to comply with the CFR 45 Appendix A Security rule. The client software provides the decryption key and the data is decrypted on the server and then sent to the client.  In most cases the client (a database driver in an MVC application such as Ruby on Rails or CakePHP or ASP.NET MVC is also a server side resource and often lives on the same physical server as the database server. This is not a bad thing.

3. Encrypt entire data partitions

Encrypting entire data partitions has its place.

On Linux, encryption can be layered on top of a file system using a “loopback device”. This allows an entire file system partition to be encrypted on disk, and decrypted by the operating system. Many operating systems support this functionality, including Windows.

Encrypting entire partitions is a security countermeasure for physical attacks, where the entire computer is stolen. Research we did in 2007 indicated that almost 50% of large volume data breaches employed a physical attack vector (stealing a notebook at a hotel checkin desk, hijacking a truck transporting backup tapes to Iron Mountain and smash and grab jobs where thieves know the rent-a-cop walkaround schedule and break in and steal desktop computers.

On the other hand, once the volume is mounted,  the data is visible.

4. Encrypt socket communications between server tiers

SSL has it’s place, although SSL is not a silver bullet countermeasure for Microsoft Windows vulnerabilities and mobile medical devices vulnerabilities as I wrote herehere and here.

SSL connections encrypt all data sent across the network: the password, the queries, and the data returned. In database client-server connections,  relational database systems such as PostgreSQL allow administrators to specify which hosts can use non-encrypted connections (host) and which require SSL-encrypted connections (hostssl). Also, clients can specify that they connect to servers only via SSL. Stunnel or SSH can also be used to encrypt transmissions.


Tell your friends and colleagues about us. Thanks!
Share this

Are passwords dead?

A recent article on CSO online ponders the question of whether or not passwords are dead – since they are not much of a security countermeasure anyhow (or so the article intimates). The article quotes a person who seems to believe that SQL injection attacks have to do with password security.

Christopher Frenz, CTO at See-Thru and a faculty member at Mercy College, both in New York, says the problem is, “not because of passwords being obsolete, but because of the prevalence of bad passwords and bad password practices.”

He points to the 2009 SQL injection attack on the social media site RockYou that compromised 32 million user account passwords. “The only password security requirement was a password of at least five characters,” he says, “(which) resulted in people choosing passwords such as 12345, Password, rockyou, and abc123,” plus common dictionary words.

Besides that, the passwords were stored in plain text format, along with users’ email addresses.

Frenz says some websites (Hotmail recently among them) now require more complex passwords with multiple character types.

I’m speechless.

SQL injection attacks on Web sites are made possible because of poor coding practices that take input strings from forms or query strings and concatenate with SQL snippets like this:

2′;Update tbl_accountParent set Email=Email+’;obama@whitehouse.giv’;select * from  tbl_accountParent where ‘1’=’1

From now on, whenever any user asks for password reminder, Mr. Obama will get a nice email with his user name and password.

And frankly, I don’t understand programmers or Web site operators who tolerate storing passwords in plain text or encrypting them instead of using one-way hashes

Maybe a bunch of people should read the online introduction to cryptography by Dan Bernstein.

Tell your friends and colleagues about us. Thanks!
Share this

Data at rest encryption

Two days in the same week to run into FCPA issues is strange.

A prospect in Poland (ENEA) recently acquired Euro 6 million worth of disks from Hitachi and explained the purchase as a data loss prevention measure (Hitachi has data at rest encryption- i.e. the controller encrypts the data on the disk, which makes it unreadable if the disk is ever stolen).  The outstanding aspect of the deal is that it was done without a public tender. The details are a bit fuzzy but it appears to have been done by breaking up the order into a large number of small purchase orders below the RFP requirement. It’s highly likely that there was some money paid under the table for expediting the transaction.  People in Poland are predicting that it will eventually end up in a criminal investigation.  Hitachi Data Systems is a US company and needs to be compliant with the Foreign Corrupt Practices Act – and a bribe even via a third-party intermediary, is illegal under the FCPA – as companies like Johnson and Johnson and Monsanto know well.

Tell your friends and colleagues about us. Thanks!
Share this

When should you encrypt email?

A while back, a colleague asked me what is the best way to encrypt internal email.

My first question to him was – what is the threat,  who is  the attacker and what is the asset you are protecting? Are you trying to encrypt business communications between employees and vendors/customers to protect from eavesdroppers or do you want to encrypt the message repository and protect it from attackers?  Before  applying encryption as a security countermeasure do a little threat analysis first.
My experience with data loss prevention with systems that monitor millions of transactions and hundreds of violations a year has shown the following:

a. It’s  better to use outgoing email in clear text because

1) you can monitor what people are doing  and

2) having  a business partner decrypt/encrypt is generally a pain in the ass that is greater than the value of the business transaction.

There is little reason to encrypt internal email in my experience. Let’s say that Mike in sales has an insider tip on company  stock options and he wants to tell Candace in HR.  Encryption doesn’t mitigate that threat. Let’s say that Joe has a secret algorithm he wants to sell to Gene who works the dark side. Encrypting internal email won’t mitigate that threat either. If there are confidential files being sent by email to external destinations – encrypt the files and give the key to the recipient.

If you’re concerned about data leakage then your cheapest and most effective countermeasure is monitoring email transmission for particular data types and destinations.

b. If you have high-value business communications between your company and vendors – you are better off just encrypting  the file (for example a sensitive contract or product design doc) and sending  the encrypted attachment.  This will enable you to monitor who is sending and who is receiving and with the right monitoring system – you will be able to detect that an encrypted file was sent which is interesting information in it’s own right.

Read my blog entry on this topic http://www.software.co.il/blog/2007/06/secure_communications_without_1.html

Tell your friends and colleagues about us. Thanks!
Share this