There are a lot of reasons to hate passwords as an authentication mechanism – the fact that users hate them, easy to guess/brute force, overhead involved in maintaining the system when credentials, are forgotten/lost, overhead due to locked out users, over reliance on a single factor of authentication, etc, etc. All of it comes down though to one central theme: using passwords put the responsibility for security on the users and not the security folk, and this is a huge mistake. Users are not trained security professionals, and they can’t be expected to be. It is simply unreasonable to expect users to create unique strong passwords for everything they access, remember them, not write them down, and never forget them. They have other things to do, and security is just not one of them. I don’t want my employees to be the primary line of defense for IT systems I’m responsible – I want qualified security personnel. If you use passwords for authentication, then that’s essentially what you’re doing. This is the root cause of all the other problems with passwords.

In the latest issue of 2600 is an article on voicemail passwords. Because of its source it’ll be largely ignored by the mainstream, which is a shame because it actually has some good data. The author had access to a system with 40,000 voicemail passwords which were stored in plaintext and did some analysis on them. I always like having access to real data, especially when it so nicely demonstrates how people actually use security. In this sample, there were no complexity restrictions placed, although passwords had to be between 3 and 10 characters, and were obviously numeric. Some interesting facts:

• The top 17 or so passwords accounted for about 25% of all passwords in use. That means you could crack one out of every four passwords in 17 guesses.
• The most common password (accounting for 9.4% of the passwords in use) was the extension itself.
• Shorter passwords were greatly preferred over longer ones. (This shouldn’t shock anyone).

The most interesting thing though, was the distribution of passwords by length, which I’ve reproduced below:

So, even though shorter passwords are more common, passwords of an even length are more common than the odd number which immediately precedes them. (The one exception is 7-8, where 7 is more common, perhaps because people use a 7 digit phone number as a password). The main question on my mind of course is why – does the human brain find it easier to remember string of numbers in pairs? Do people just like even numbers more?

Well, the Verizon DBIR contest hasn’t been solved yet (or at least, Verizon Business hasn’t announced that it’s closed), so I decided to take another stab at it. Twitter doesn’t seem to include my tweets in searches, so no one saw my initial tweets on the subject, but today there were other people tweeting about it. The main focus right now seems to be stego data in the image on the front cover. I followed this line of thought for some time on Monday, so I figured I’d law out my thoughts here.

When extracting images from the report, the front cover has 2 main images – one of a blue fingerprint, and one of a grey one. When run through stegdetect it says that the later has 10 bytes of data before the 0x9d flag. I tried to get the data out with fphide, but fphide requires a key to extract. Since I had no more leads on another key, I had to give this up quickly. I tried stegbreak using both the john the ripper wordlist and the report itself as a dictionary to no avail. I also manually obtained the 10 bytes with a hex editor and tried using that as a key to break the encrypted data, but what algorithm uses an 80 bit key? (And I still don’t know the algorithm or the iv). I’m currently leaning back to my initial position that there is no steg data for four reasons:

1. What can you really hide in 10 bytes?
2. If you google this, you’ll see a lot of people have this issue. It could very easily be an artifact of the program which created the image. *cough*Adobe*cough*
3. Getting the images out of the doc seems to require either Acrobat pro or a third party app. I find it hard to believe that the creators of the puzzle would require either of those.
4. The clue on ZDnet says so.

That is of course speculation on my part, and I could be wrong, but that’s the assumption I’m working on going forward.

On a related note, this is far more fun to do with other people. I think I finally see the value of twitter.

This morning Verizon Business announced that the DBIR contains a secret code. I promptly set about to try and crack it. I feel that I’ve made significant progress, but I have to stop now and I won’t have a chance to resume for a few days, by which point I’m sure it’ll be over. In the mean time, I’ve decided to share my results so far here in the hopes that my experience will help others, or perhaps others can point out flaws in my logic.

The first thing to note is that on the back cover, in black text on a black background, is the following block of code:

U2FsdGVkX1/igcsdctD3brMu4vDXkswNZZoHL6QVcI6eBlfN4aqvBBowRhf9wfsk
hb5RIGVSpphM2bJe33tVKh7koZ85V5ebFI1mPlXEhnKHO+er8EIyDRYuVvju08qv
u/jITmGEM4Mpk4gvL7aVeFB5lxoMFo0ds/CEA6zK80QprvV5B+c6+MWciIzLFJWI
/4OcO96UGM2riMKj2iy4JgmRxjEUyX/TKQEIB1s7WLh6cW30JpvgAI8wILVdTWpt
+gnIfyEGxio4Q2T9LM1ncA5K2P4lg/DsTiDIEEg3Ws4uW5sbz22qfE91frW7NnBg
t46Iy0WhZgw0+wj4DCLzF4GBnIkplanSMdA+hiwhdR629KL7O8X1ZLg5eFHmjS6C
VCXXuQJVSaVG77/5113N/eNMboD2RhXyq1kWzZZaW/lpJ8vIDs5OK7d1TPG6aVLJ
hINx3qPZzNvtK4r4KfZ5fhjUXLcufOpE46gGnD0aHW+SCcGl2k7NPqbYfGtYSwuJ
HYne4VTxR772vsV5RFgirw==

Clearly it’s no stretch to imagine that this is a major clue. After spending several hours convinced that there was steganographic data encoded in the image on the front cover, I turned to analyzing the code block. The first several characters – U2FsdGVkX1/ – are the base64 encoding of “salted__”. What I have since learned is that when you encrypt something with a salt, the resulting ciphertext includes that string followed by the actual salt so that it can be decrypted. (Thus an awful lot of cipher text begin with U2FsdGVkX1 – the slash is sometimes a different character that has to do with the peculiarities of base64 encoding). If this has been salted, that means is has been encrypted. If it’s been encrypted, that means it can be….. unencrypted! I tried a lot of educated guesses at the passphrase, none of which have yielded a positive result yet. Part of the problem is that I know neither the key nor the algorithm. My last ditch attempt was to take the DBIR, convert it to text, use it as a dictionary, and then try each word as a key for AES128, AES256, DES, 3DES, blowfish, etc. My quick and dirty shell script is here:

for line in `cat dict`; do
  `openssl aes-128-cbc -d -base64 -in textblock -k $line`
done

for line in `cat dict`; do
  `openssl aes-128-ecb -d -base64 -in textblock -k $line`
done

repeat for 3DES, blowfish, etc., etc.

I have a feeling that the answer to either the algorithm or the key must be in the report somewhere, I just can’t find it. I hope this helps someone. (And if it does, please let me know).

In the Verizon DBIR report they have an interesting graph on page 26. It shows the percentage of malware infections that have been customized. (That is to say that the malware itself is customized). In 2005-2007 the percentage held steady between 21%-28%. In 2008 is jumped to 59% and in 2010 is it still high at 54%. Perhaps not surprisingly, even though only half of the malware is customized, that half is responsible for 97% of the stolen records. Presumably non-customized malware and all other methods are responsible for the remaining 3%. Why the huge discrepancy? It’s easy – antivirus. Non-customized malware gets detected, customized doesn’t. This just goes back to something many people have started to feel in the last few years – antivirus is inherently flawed, and we’re starting to see it’s flaws. Blacklisting is inherent a losing battle, because there will always be new bad things, and there will always be something you didn’t think of. Whitelisting may seem like a pain at first, but in the long run it’s almost always easier and more efective.

I just got a spam email from a company trying to sell me something-or-other for email that included the following quote:

“Most organizations are struggling with the rising tide of email attachments, which can rapidly consume all available email storage when left unchecked.”

They attributed this quote to Matthew Cain, which I can’t verify, but my only response is: Really? I mean really? In this day and age? Are you sure this quote isn’t from…. 19992?

It’s amazing how quickly something can go from “brand new” to “mandatory reading’, but that’s exactly what the Verizon Data Breach Investigations Report has become in its short existence. The 2010 report has been released. The total number of cases analyzed since the inception of the report is now over 900, and is easily the largest data set to date.

In the previous post I mentioned multi-domain certificates but not wildcard certificates as a solution to the problem. The reason I didn’t mention wildcard certificates is because they have their own inherent security risks. If one subdomain is compromised, all subdomains may be compromised. (Verisign even states this clearly on their page on wildcard certificates.)

When it comes to preventing users from entering their data into fake websites, the main defense people always rely upon is user training. We’ve tried for years to train users to always look for the little lock icon that indicates the site is using SSL. Now we’re starting to train them to look for the EV cert. Browser makers have gotten much better about making it more difficult for a user to bypass certificate errors. One of the biggest mistakes an entity can make is accidentally training their users for bad behavior, such as accepting certificate errors. Unfortunately, that is exactly what many people are doing. Many times someone will buy a certificate with their main www domain – for example www.bankofamerica.com, and forget about the domain bankofamerica.com. While the difference may seem trivial, any user that enters https://bankofamerica.com into their browser will be met with a certificate error, which they will ultimately have to accept if they want to continue. This is bad practice all around.

To prove my point, I decided to look at the 10 largest banks in the US and discovered that four of the ten exhibited this flaw. (Bank of NY Mellon does not seem to have a login on their main domain, and therefore don’t utilize SSL period). One would think that for a large financial institution like one of these, getting a multiple domain certificate would be a simple task, but apparently they never thought to do it. In the mean time, they’re training their users for poor security practices.

There’s a new full disclosure website in town – http://www.vs-db.info names and shames those with web application vulnerabilities (like SQL injection, XSS, XSRF, CRLF injection, etc.), without providing enough details for exploit.