#ThingsI'veSaidInMyHead

"He didn't just burn bridges. He flew over them in an A10 Thunderbolt, strafed them with the Gatling gun, bombed them into rubble, and then landed, walked over to the smoking ruins, and desecrated them with bodily functions"

The Idiot Sieve

In my years as an IT professional, from cabling through security, I have noticed a recurring phenomenon; The Idiot Sieve.

It goes a little something like this:

Start with a reasonable mixture of talented, average, and struggling team members.
Reward social interaction equally or even superior to actual results. (Toadies and bootlickers)
Fail to rectify failure and incompetence.
Pay 10 people to do 10 peoples worth of work while only 5 people are actually contributing.
Let the slackers slide.
Keep pissing off the competent and talented by coddling the fools and idiots.

Result:

The people who are good at this will go in search of a place that recognizes and rewards such things.
The idiots will have nowhere to go and no incentive to NOT be idiots.

Eventually, will sieve out the idiots and the talent will pass through to another place.

Voila!

Idiot Sieve!

Moving swiftly onward...

I love hacking stuff.

Not in the "I'm going to steal your credit card numbers!" way, but in the "I wonder how THAT works?" way. I do admit to a certain visceral thrill to being able to get to the place where I COULD do bad things, but once I get there, I am not interested in the actual stealing. Doing that kind of work for a living has been a dream for years. I have had that exact gig with two different companies over he last four and a half years. It's not been 100% of what I have done, but it was enough to be fun. This sort of cool gig comes with constraints though. More so in this last iteration than the one before. Previously I worked at a smart meter manufacturer. Part of my job was to figure out how someone could hack a meter or the system supporting it. It included some very cool work, and as long as I didn't expose any trade secrets, put a utility at risk, or worse yet put lives at risk, I was allowed to publish. Still, I was able to produce some cool findings and land some speaking gigs while I was there. I figured that moving to a firm that specialized in that kind of work would mean doing more of it. 

Not so much...

It turns out that doing research like that doesn't make all that much money. That means it doesn't come along very often and in order to keep the lights on, you have to do the "boring" stuff. It also, ironically, turns out I am pretty good at the boring stuff. Much to my surprise I actually like doing it. As a result, I wound up doing primarily compliance work. Some pen testing, but mostly compliance. Now, there are a lot of people who are better at hacking and pen testing than I am or will ever be, so when the cool stuff comes in, the people who can really rock it get to do it. That means I have not been able to do the cool stuff I enjoy all that much in the last two years. What cool stuff I have been able to do, either on my own or for my employer I have had to stay quiet about because the stuff I hack, when I break it, upsets companies who make the stuff. Companies that may otherwise want to do business with my employer. That other stuff is worth more money than my cool hacks, so it's not a good idea to piss them off by breaking their stuff gratuitously and then publishing it. That's just smart business. Companies don't exist so people like me can do cool stuff, they exist to make money. Thus was I able to do cool things that I simply couldn't brag about. I kept up doing what research I could afford on my own, but it's not as much fun when you can't show it off. 

With the realization that I enjoy building compliance programs I have decided to change employers and positions to one where I can focus all my career energy on building a compliance program for an organization that both wants and needs it. They want the work I am doing, and they like the way I do it. I like having a "normal" nine to five job where I rarely travel because I've spent the last ten years of my career being away from home more than half the time. 

I have missed the majority of my kids lives. Not cool. 

The new gig will have me working from home the majority of the time. Very cool.
All this equals a new job. The place I am leaving and the place I am going aren't terribly relevant to the point I want to make here. Suffice to say that the employer I am leaving is a well respected security consultancy and the one I am joining was a client of theirs.

So the Other cool thing is that I get to keep doing security research. I never actually stopped. The difference is that it won't be associated with my employer, I am just doing it for the sheer joy of hacking. If I offend a manufacturer by finding a flaw in their product, I don't have to worry that they will decide not to do business with me or my employer.

Meaning:

I can publish. Or not. 

I can rant. Or not. 

I can break stuff and show it off. Or not. 

I can speak at conferences. Or not. 

I can speak my mind. Or not.

No editing. No toning down. no more people with no experience in my topic trying to get a word in.

The only rules are "Don't be a d*ck." and "Don't violate existing NDAs"

My current research projects include practical cryptography in IoT, embedded, and PCI, some oddball RF stuff with satellites, the usual social engineering + wifi stuff, and anything I can make an SDR do.

Stay tuned...

PCI and Encryption - The Good, The Bad, and the Frankly Stupid

Introduction

     Recent news in the world of compliance, security and cryptography has drawn attention to how things are encrypted, and whether that encryption can withstand an attack. Particular attention is being given to the credit card industry because it touches almost every American’s life. As the people who actually assess PCI environments, this means that we as QSAs need to ensure we have a solid understanding of what it actually means to encrypt something. 
     The PCI-DSS 2.0 standard, requirement 3 states: “Protect stored cardholder data”. Requirement 3.4 further refines this to “Use strong cryptography”, but what does that really mean? 
     The usual approach is to cite NIST standards which basically state “Don’t use DES. Use Triple DES or AES”. What the NIST standards we look to for guidance fail to do is define HOW to properly implement these approaches.

     NIST does have fantastic guidance on implementation, but it is buried in an arcane indexing system that almost requires an advanced math degree just to understand in itself! Encryption is one of the few areas of security where you can be provably secure, and rely on something concrete for protection. Sadly, many developers and assessors don’t have a strong grasp of the intricacies, or even the basics of cryptography. As such, the PCI world seems plagued both by poor implementations of crypto, and poor assessment of those implementations. Encryption is the area of data protection where I see the biggest missteps and misunderstandings – both among those who implement it and those who assess it. In this paper we will examine some of the real world implementations seen, and why they fail the test of “Strong Cryptography”. Our intent is not to educate the reader on the subtleties of ciphers and modes, but rather to examine some of the missteps taken in the implementations seen during various PCI-DSS assessments. We will focus on actual encryption of data here, and not on related concepts (such as hashing or tokenization) which often get mixed up with encryption and misapplied. 
     Cryptography is only as strong as its weakest element. The most secure, unbreakable cipher is easily compromised by a weak implementation. The most common source for these missteps stems from either a default configuration of a software package like the DBMS, or in-house development without having a clear understanding of how crypto should be configured or how keys should be managed. 

Cipher Choice - An introduction to AES and Triple-DES 

     There are dozens of different ciphers available for use when encrypting data; however PCI implementations tend to use either 3DES or AES as they are the most widely recognized, implemented, and portable ciphers. Other ciphers are allowed, or at least not prohibited, and the same principals applied to 3DES and AES are equally applicable to other ciphers. 

Triple-DES

     Triple-DES (3DES or TDES) is an update of the older and now deprecated Data Encryption Standard (DES) mode. Like DES, 3DES uses a 64 bit block size. Unlike DES, 3DES takes the plaintext through 3 cycles of cryptography where it first encrypts, then decrypts, then again encrypts the data. When properly implemented, this is done with a 192 bit key that is used 64 bits at a time in each cycle. 
     The first 64 bits is used as a DES key to perform an encrypt operation on the 64 bit plaintext block, then the middle 64 bits is used to perform a decrypt against the ciphertext from the first operation, further scrambling the data. Finally, using the last 64 bits of the key, the product of the decrypt function is encrypted. This works because of a property of DES where encrypt and decrypt operations use the same sequence, with only a reversal of the key schedule to perform the decrypt. 
     The cryptographic strength of 3DES is highly dependent on how the key is constructed which is demonstrated later. 3DES retains some DES properties, such as the reduction of the key block size from 64 to 56 bits by discarding every 8th bit. The repercussions of these design decisions is outside the scope of this paper, however a number of well written discussions about the S-Box, key strength, and key scheduling can be found with a bit of research. 

Advanced Encryption Standard (AES) 

     AES was announced by the NIST as U.S. FIPS PUB 197 (FIPS 197) on November 26, 2001. The AES cipher was developed to address the weaknesses identified in other ciphers and provide more robust cryptography. Although 3DES is still allowed per NIST recommendations AES is the preferred cipher today. 
     
     The AES cipher differs from 3DES in three important ways: 

• It uses a stronger implementation of the substitution box with the Rijndael approach, 
• It uses a 128 bit block size instead of 64 bit, 
• It uses different keys sizes (128 bit, 192 bit, 256 bit) depending on requirements. 

     While there has been some development on proposed versions of AES that expand the block size to 512 and 1024 bits, these implementations are experimental and not appropriate for general use. Like DES and 3DES, AES retains a strict block size, necessitating a padding solution like PKCS. A real-world advantage of AES is that many processors have a dedicated hardware based AES encryption engine which increases performance exponentially over a software only implementation. 

Cipher modes – ECB and CBC 

     Most ciphers used to encrypt data today are block ciphers, where data is divided into fixed-size chunks which are each encrypted. Block ciphers use a variety of methods, or modes, to string the different chunks of ciphertext together, and each of these has advantages and disadvantages. 
     While it may feel overly pedantic, choosing the right, or wrong, cipher mode can significantly affect the security of the encryption in practice. The key to success is to balance these in a way that provides the cryptographic strength you need while not adding too much processing burden to your system. The two relevant modes for this discussion are ECB and CBC because they are the two most common block modes used to encrypt PAN numbers (discussed later). 

Electronic Code Book 

     The Electronic Code Book (ECB) mode was the first block mode utilized. ECB is the simplest and most straightforward block mode. Each block is independent from the others and any given piece of plaintext with result in exactly the same ciphertext, every time. This makes the cipher highly parallelizable and results in the fastest implementations. 
     This property of ECB mode is also its greatest weakness. If a plaintext can be found that fits within the block size of the cipher, that will always produce the same ciphertext. That may be an account number, a word, any sequence that is in the same place in each message. Using this, a cryptanalyst can infer a great deal of information from the ciphertext without having to actually decrypt the data. The penguin to the right is a good example. 

Chained Block Modes 

     Weaknesses resulting from the way ECB treats each block independently resulted in the development of other modes where each block was treated differently. Examples include Cipher Block Chaining (CBC) and Output Feedback (OFB). These use an additional piece of data, called the Initialization Vector (IV), as an input to the encryption process. 
     An IV is used as a seed value in block modes like Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR). Each of these needs the IV as a starting point, and then they have an internal mechanism that uses some preceding data, such as the last piece of ciphertext, as the IV. Some modes have a dependence on non-predictability as well, but they are outside the scope of this paper. 
     The IV is a piece of known data that is the same size as the cipher block which is XORed with the plaintext to be encrypted. The IV does not need to be kept a secret, as a matter of fact, when used correctly it MUST be known to complete the decryption. The most important property of an IV is non-repetition. The properties of CBC discussed here are common across all of the block chained and IV dependent modes. Any given plaintext, if submitted more than once should only have a chance of producing identical ciphertext. Naturally, this is diluted by the cryptographic strength of the random number generator (RNG) in use, but for the purposes of this discussion, we will assume a hypothetical perfect RNG. 

Input Entropy - Why what you are encrypting matters 

     When you have a type of data you need to encrypt, it is important to understand the nature of that data and the impact it may have on the cryptographic process. The ideal cipher will make your data appear as much like random noise as possible. The appearance of randomness is affected by both the cipher, and the data you are putting through it. 
     The more possible values you have, the more random it can appear. For example, if you are encrypting something that only has two values, like “true” or “false”, you will only get two pieces of ciphertext. As an attacker I have a 50/50 chance of getting it right each time. The more complex your plaintext, the more complex your ciphertext will be. It is this property that makes credit card data so interesting from a cryptanalysis perspective. 
     The piece of data of most interest for encryption under PCI-DSS is the Primary Account Number or PAN. The PAN has properties that make it interesting and challenging from a cryptographic perspective. 

PANs are not random

     Many developers depend on the apparent randomness of PANs to be an element of the cryptographic strength. Although PANs appear random, they are not nearly random enough to be considered for use as a cryptographic element. The first part of the pan indicates what the card brand and issuing bank are, and the last digit is a checksum. That leaves only the parts that the issuing bank generates, and that is simply too small to be useful as a source of randomness 

PANs are not long enough 

     Ciphers that use various block chaining modes rely on data that exceeds the block size in order to be utilized properly. PANs are, at their longest, 16 characters. This equates to 16 bytes or 128 bits of data. Exactly two 3DES blocks or one AES block. Most cipher implementations will add a block filled with padding data, either all zeroes, PKCS5, or PKCS7. In any of these cases, the last block of data will consist of a known value. If CBC is in use, that value will be XORed with the ciphertext of the previous block, but because both values are known, this is of little use. In fact, it provides a potential crib (plaintext used in cryptanalysis) depending on how the underlying implementation handles padding data.
Because PANs typically fall on a block boundary, unless CBC or some other chained mode is used with a proper IV implementation, at best the cryptography is only as strong as ECB equivalent. 

Key management - The dangers are in the details 

When it comes to cryptographic key management there are many ways to do it right; here are some of the ways to do it WRONG. This is all far from an academic exercise; the examples cited below have been seen in real world production environments. The first place an attacker is going to look if they want to compromise your cryptography is in things which they have access to. Why guess it when you might be able to find it with a little digging? 

Keys in source code 

Embedding cryptographic materials in source or executable code is one of the oldest, easiest to avoid, and yet most prevalent mistakes made when implementing cryptography. An attacker will search in the source code if they can get it, and in the executable next. It is the embedding of keys and passwords in code that lead to PCI-DSS 2.0 requirement 6.5 which, among other things, requires training of developers to avoid this critical mistake. 

     Some of the examples seen in the wild are: 

• Actual plain text keys in source code, PHP, even HTML 
• Formulas used to derive a key or meant to obfuscate the key embedded in source or PHP
• Static IV included in the source code 

Copy and paste an example 

     Many applications have example configuration included or documented somewhere convenient. Often times a developer or DBA will simply grab that example and paste it into a running configuration and assume that all is well. 
This is not so. - It is these defaults and examples that an attacker will try first, and sadly, they often succeed. 

Weak or NULL keys 

     It is often tempting to use easy to generate, short, or null keys, especially when embedding them in code. Shorter keys are easier to brute force, and in 3DES they defeat the purpose of how it uses the key (see the section on Triple-DES earlier). While these are easy mistakes to avoid, there are some other factors that can lead to a weak key. 
     Some systems allow you to use a short alphanumeric key and simply translate that into ASCII to get a hex value and then pad the remainder to get the 128, 256, or 512 bit key for AES or the 192 bit key for 3DES. The more prudent approach is to use a passphrase and then use a hashing function like MD5 or SHA to produce an appropriate length key and discard either the most or least significant digits to make it fit the key length. 

For example the password “letmein” becomes:

0x1C8BFE8F801D79745C4631D09FFF36C82AA37FC4CCE4FC946683D7B336B63032 

with SHA256.

This is a much stronger key than the plain hex value:

0x6C65746D65696E00000000000000000000000000000000000000000000000000

     If the plain text key above were used in a 3DES implementation, the result is the same as though DES were used. The first 8 bytes (64 bits) are used to encrypt, then a key is used to encrypt and decrypt the result, canceling out the last two cryptographic functions of 3DES. 

Bottom line: 

“letmein” is a classic example of a REALLY bad password 

0x1C8BFE8F801D79745C4631D09FFF36C82AA37FC4CCE4FC946683D7B336B63032 is an EXCELLENT password (assuming it is salted) 


     Some of the examples of weak keys seen in the wild are: 

• “0×0” 
• “0xFFFFFFFFFFFFFFFF” 
• “0x0123456789ABCDEF” 
• “0×0101010101010101” 
• “ABCDEFGHIJKLMNOPQRSTUVWXYZ” 
• “password” 

Static or NULL IV 

     Because using dynamic IV requires that it be stored and relatable to the ciphertext, many developers will use a static or NULL IV. Using a NULL IV is mathematically the same as not having an IV, and a static IV results in a limited improvement in cryptographic strength which becomes evident when a large data set is observed to have duplicate ciphertext values in different records. To use an IV properly, the field where the ciphertext is stored will have to be enlarged by the block size (e.g. 8 bytes for 3DES, 16 bytes for AES) to accommodate the IV value. 
     An argument that is commonly brought up to justify not using a dynamic Initialization Vector (IV) is that the PANs represent sufficient randomness. But, PANS simply are not random enough. 
     Based on a byte and bit level analysis of PAN structure and ASCII encoding, the highest possible entropy available would be 64 bits, because the remaining 64 bits are fixed and known. The very nature of PAN data renders it even less effective as a source of randomness because of the constraints of the IIN portion of the number as well as the requirement to pass a Luhn (checksum) calculation. 

Using the built-in encryption without understanding how it works 

     Many DBMS systems have a built in capability to encrypt data at a field level. Research into some of the recent releases of open source packages has shown that either they have obtuse documentation that requires a substantial understanding of cryptography, or they lack sufficient encryption capability to be considered “strong cryptography”. 
     As an example, MySQL has a field level encryption function, however the default implementation is weak. Only two ciphers are offered, AES–128 and 3DES, and there are limitations with them. 
     The 3DES implementation only runs as CBC, offers no obvious IV functionality, allows the use of a NULL key (One comprised of all zeroes), pads keys that are less than 192 bits with zeroes, and uses NULL keys as the default. 
     The AES implementation eliminates some of the issues present in the 3DES functions, but it presents different challenges. AES only runs in ECB mode and uses an unknown padding method. Using ECB typically precludes using an IV unless you implement it prior to encryption and store the value in a separate field. 
     While it is possible to add appropriate cryptographic functionality to MySQL, it requires a fair amount of customization both in the implementation as well as source code modification. Postgresql has a more robust encryption facility built-in, however it is based on GPG and access to cryptographic primitives is a byzantine process, and unless the developer or DBA has a strong knowledge of how cryptography works, it is easy to misconfigure. 
     This is not to say that ALL DBMS packages have weak crypto. Rather, it points out the importance of understanding how crypto works, then understanding how your applications apply it. 

Conclusions 

     The key to implementing strong cryptography lies in the following principles: Understand the data you need to protect (PAN data) Understand what your system is capable of (AES? 3DES? ECB? CBC?, IVs?) Understand what constitutes both strong and weak crypto (Use IVs, CBC, Strong keys, good key management) Understand what the requirements are for the compliance framework you need to follow, and then exceed them. 
     PCI-DSS only defines the required protection as “Strong Cryptography” and avoids defining exact requirements. So what should we, as developers and assessors use as a baseline for what constitutes strong?  

Going forward - A minimum standard for PCI and crypto 

     OK, so all these ways to do it wrong, how about a way to do it right? Stick to the following as a minimum standard for encrypting CHD, and there should be no issues with either passing a PCI-DSS 2.0 assessment or with providing reasonable protection to the data. 

• Start with a well-known and tested cryptographic library. NEVER ROLL YOUR OWN!!! 
• Use AES because the PAN fits inside a single block. 3DES breaks it into two blocks. 
• Use the largest key your system will support. 256bit is best. 
• Use Cipher Block Chaining mode, not ECB, because it the IV component provides a significant improvement in cryptographic strength. 
• Use an IV that is unique for each record. You can start with a random number and count up. Use randomly generated keys, and then hash them with SHA and use the hash output as the keys 
• Manage your keys like the thing they are; the one thing that can unlock all of your secrets. Test it. 
• Break it. 
• Fix it. 
• Repeat. 
• Do this until you can’t break it. 
• Then have someone else do the same thing to it. 

     Implementing strong cryptography isn’t easy, but it’s not significantly more difficult than implementing weak cryptography. It is definitely easier than either fixing weak cryptography or dealing with the consequences of exposed data. 

No-one ever got fired for having encryption that was too strong.

A Security Zen Koan- The Master, The Villager, and the Clay Jar...

A Security Zen Koan...

The Master and a group of students were traveling down a road, when they were accosted by an angry villager.
The villager scolded the Master thus; "I came to you for advice on which firewall to buy. I bought that same firewall and installed it. Days later, my system was infiltrated by ronin from a neighboring village and they plundered at will! How could you lead me so astray?"

The Master pondered this for a moment and then replied thus; "You followed my advice to purchase a firewall. You did not follow my advice on how to go about configuring it. If you buy a clay jar from a local pottery artisan, fill it with fine wine, and then place it on the floor to use as a doorstop, do you accuse the artisan of incompetence when a guest kicks the jar over and shatters it, spilling your fine wine?"

The Master then struck the angry villager with a large invoice, and the villager was enlightened.

On the assumption of encryption. A Zen Security Koan

The Master and a Student were conducting a PCI gap analysis for a Client.

The Master asked the Client's Server Administrator if they encrypted their backups, to which the Administrator replied "No, but surely the database team encrypts the data, so I do not worry about such things."

In the next meeting, the Master asked the DBA if they encrypted the PAN field in the tables, to which the DBA replied, "No, but surely the backups are encrypted, so I do not worry about such things."

The Master took the Administrator and the DBA to the roof and politely asked them to to climb into wooden boxes. When the they complied with his request, the Master pushed the boxes off the roof.

Shocked, the Student asked the Master why he would do such a thing.

The Master replied "Surely the DBA and the Administrator brought pillows with which to cushion the fall, so I do not worry about such things".

And thus was the Student enlightened.

Dear Developers/Programmers,

If you have been putting passwords and keys into your source code, you CANNOT hide it from me by using .NET Obfuscator. If it is usable to you, it is findable by me.

ANY Developer found including passwords, initialization vectors, keys or other sensitive cryptographic material shall be summarily fed to the C'Thuhulu beast in the catacombs of the corporate offices.

Sincerely,
The Security Lab

The usefulness of objects - A Zen Security Koan

One sunny afternoon, the Master and his Students were reviewing the results of a security assessment with the Villagers.
After discussing one result, a Villager spoke up and said,
"But Master, that interface was not designed to be used that way!"
The Master picked up a nearby umbrella and poked the Villager hard enough to draw blood.
Thus was the Villager Enlightened

禅

The Journey - A Zen Security Koan

A Villager came to the Master and said, 
"Every year I pay your disciples large sums of money to test my security. Why must I do this?"


The Master replied, 
"Each day, the Shepard walks along the perimeter of his fence with his dog. Does the dog only journey home?"


The Master then struck the Villager upon the head with a large invoice. 


Thus was the Villager Enlightened.

The Master Explains Compliance - A Zen Security Koan

The Student came to the Master and asked,
"Master, why is it that I am compliant, yet I am not secure?"
The Master replied, "Compliance is not security."
The Student then asked, "If I become secure, will I be then compliant?"
The Master hit the Student over the head with a large invoice.
Thus was the Student Enlightened.

More Security Theater

EFF has a great piece about the whole stir regarding the new TSA whole body scanners or Advanced Imaging Technology (AIT) as it's formally called.  In essence TSA has moved aggressively to deploy the scanners at an enormous cost without validating whether the scanners address the threat they are meant to find - namely easy to conceal, hard to detect powder-type explosives.  As EFF reports in their post, it turns out that the scanners are fairly easily confused - even by folds of clothing.  Additionally these scanners were developed to detect more traditional threats - weapons, liquids, and more traditional explosives like C4 and plastique.  Powder was not one of the drivers in the development of these scanners.   EPIC has filed a lawsuit against TSA demanding that the deployment of the AIT scanners be halted pending an independent review of their effectiveness.

It's interesting that the EFF article quotes a former chief security officer of the Israel Airport Authority who calls the scanners "expensive and useless . . . That's why we haven't put them in our airport."  Yes, and TSA should pay attention to the Israelis experience...they have had a successful track record at Ben Gurion airport and of keeping terrorists off of planes - and they don't need to "touch your junk"!

A snowball of traveler outrage

The whole TSA grope fest is gaining a bit more press than I think they'd like...

This is just messed up...
http://gizmodo.com/5688087/the-tsas-sense-of-humor-makes-me-nervous
Follow the money...
http://gizmodo.com/5689759/tsa-full+body-scanners-protecting-passengers-or-padding-pockets
Want to know where the new technology is set up and running?
http://www.flyertalk.com/forum/travel-safety-security/1138014-complete-list-airports-whole-body-imaging-advanced-imaging-technology-scanner.html

Fresh rage...

Ok, I know this is supposed to be a place to put funny stuff from the security industry... BUT...

(I apologize for the ranting, rambling, link heavy content)

I have been thinking about the new security procedures at the TSA check points. There have been some "interesting" changes of late.

First, we now have the two new technological fixes for underwear bombers; MilliMeter Wave (MMW) and x-ray backscatter scanners. Cool, technology is a good approach right? HAH!!

Think they don't store the pictures? They ADMIT that they do...
http://news.cnet.com/8301-31921_3-20012583-281.html

Second, we have the new "aggressive pat down" for those who either present an anomaly or just flat refuse the new scanners. Aggressive is an interesting euphemism to employ. Frankly (based on my own observations, not hearsay) it amounts to a full on prison grope in public. Apparently they are allowed to touch your junk, check the inside of your underwear, the full Monty as it were.

A little backlash...
http://www.washingtonpost.com/wp-dyn/content/article/2010/11/12/AR2010111206843.html

After doing a little research, I found the following interesting bits to ponder...

One of the manufacturers, Rapiscan, is closely tied to Michael Chertoff. I am not certain as to his actual role as I have seen multiple assertions from lobbyist to CEO. Do a little looking around and see what you can find. What I am certain of is that he is closely tied to one or more of the makers of the scanners. Does his name ring a bell? He used to be the head of the DHS. Interesting, no?

Michael Chertoff argues for Full Body Scanners : http://www.washingtonpost.com/wp-dyn/content/article/2009/12/31/AR2009123101746.html

Michael Chertoff connection to the vendors supplying the very equipment he argues so stronly for...
http://www.boston.com/news/nation/washington/articles/2010/01/02/group_slams_chertoff_on_scanner_promotion/


Next, I had been pondering the idea of what happens when you refuse both the scanner AND the grope? Can you just say "No thanks." and go back to your car? NO!!! You are subject to civil prosecution! (I will add the federal district court case citation later today) one you enter the domain of the TSA, you can't leave freely until they have their way with you. Neat!!

http://johnnyedge.blogspot.com/2010/11/these-events-took-place-roughly-between.html

The Official TSA Guidance on Civil Penalties:
http://www.tsa.gov/assets/pdf/enforcement_sanction_guidance_policy.pdf

All this makes me wonder; what are folks who have a religious proscription against being seen naked by a stranger or touched in what amounts to an intimate manner by someone who is not family or a doctor, to do? I am thinking that a majority of conservative and orthodox faiths will have some issue with this. Naturally, ones that spring to mind are the more strict interpretations of Islam, Judaism, and Christianity. We can't profile, but we can make it so uncomfortable that the people we THINK of as the antagonists here will avoid air travel. Somehow there is this collective faulty memory that the only people who have committed terrorist acts in and against the US are Arab and Persian Muslims. Funny, I wasn't aware that McVeigh was Arabic, or that some of the crazies who always wanted to go to Cuba might actually be Persian... I mean, look how well Muslims have fared in Cuba in the last nine years!

I am thinking about a few social experiments... I am after all a security researcher, time to perhaps do some research...

A) If you, the reader, would be so kind as to spread links to this blog post, I'd like to see if TSA scrutiny goes up on me. The traffic wouldn't bum me out either ;)

B) I am going to track down a few methods to see if I can find a way to write secret messages to the screener in the back and see if any of it shows up tone InterWebs. Possible methods include: metallic fabric paint on the inside of a t-shirt, carbon fibre thread used to embroider something clever and/or rude on the band of my underwear or metallic thread in hems to do the same.

C) I am looking into having a series of t-shirts printed that say "I am not a criminal..." on the front, and "...I am an airline passenger." on the back.

D) I will be refusing the scanners and taking note of just exactly HOW intimate the grope is. I will also be interested issuing how the process differs based on how I am dressed and what
sort of carry-on I have.

Under the current rules, you have more privacy and civil rights as an arrestee than as an airline passenger. As an arrestee, there must be "probable cause" before an aggressive pat down can commence. We won't get into the more, shall we say intrusive, procedures you can be subject to. And I want to know when I was read my Miranda Rights in line???

Welcome to the next act, scene one of security theatre as presented by the Theatrical Security Administration Players for your voyeuristic pleasure...

Strong Cryptography? Really?

Working with a client about a year ago, they were trying to implement strong cryptography.

After multiple failed iterations, I explained that the cryptography had to be strong, meaning they had to use a robust encryption algorithm and an encryption of sufficient length that it could not be feasibly broken through brute force attacks.

The client's response: "We use a 14 character passphrase. Isn't that good enough?"

* facepalm *

Passwords will stop them ...

Me: "Mr. Client, you have no firewall at this Internet connection point. You really need to deploy one."

Client: "Why?"

Me: "Because you currently have no protection from hackers. Anyone on the Internet can get direct access to your system."

Client: "That's why we have passwords. They have to login first, and if they don't have a password, they can't get in."

* facepalm *

We make *blahblah*...

Me: "Mr CIO, our network is wide open, my five year old could hack it"
Him: "Oh, so what. All the important stuff is on our miniframe"
Me: "...and that's impenetrable?"
Him: "Yep, NO ONE has ever hacked our type of miniframe"
Me: --walk away, come back 10 minutes later and hand Mr. CIO his password and the root password for the system.
Him: "Oh... well we just make *blahblahblah*. No one would ever hack us"

*facepalm*

A D-?? really??

"Ms. Customer, what is your goal with this PCI-DSS gap analysis?"
"We want to pass the audit with a D-"

*facepalm*

Bolt on?

"Mr. Customer, to characterize your security as "bolt-on" would be disingenuous. I would rather say that you took security, poured it into a paint bucket and then proceeded to drizzle it over your product in the manner of a Jackson Pollock piece"

That should fix a thing or two

Okay, in theory you can post comments now... If you'd like to be a contributor, send me an email address so I can set you up...

Robert

Introduction to SecFacePalm

So you figure you will go forth and make the world a better place. Going to fix all the problems in security. It's just soooo obvious that any idiot will understand it once you explain it to the in terms they can understand...

BWAAAAAaAAAAaAa ha ha ha ha ha !!!!! (in a voice like Bender from Futurama)

This is a place to share your favorite Stupid user tricks, MBA quotes, and developer in denial babble.

Anonymous or attributed, I don't care, just bring us your security facepalm moments...

Let the laughter begin...