Password Security & Cracking ‘Em

 Computing, Security, Working Notes  No Responses »
Sep 182011
 

This blog entry is of the form of some working notes to help me get to grips with this area of security. Would welcome corrections!

There are two basic forms of password cracking :-

  1. Brute force cracking where every possible password combination is tried.
  2. Dictionary cracking where the password cracker uses a list of possible passwords to try … and optionally some algorithms for varying each word in the dictionary.
I’m more interested in brute force cracking for now, so I’ll just say a few words about dictionary cracking …

Password Hashes

Some people are under the mistaken impression that it is possible to protect against password cracking by preventing multiple login attempts – try to login more than 5 times in a minute, and the account is locked.

People trying to break into systems know about this of course, so they rarely if ever try it (the exception is multiple attempts against equipment that does not perform account lockouts). What they do is obtain the encrypted password in some way – grabbing the /etc/shadow file from a Unix system, dumping Windows password hashes, etc.

Once you have a password hash, or a number of password hashes, it is possible to attempt to crack the passwords. Not by trying to reverse the password encryption – that should be impossible, but by using the same algorithm for encrypting the password in the first place.

For instance if someone sets their password to “bad”, the password hash that gets stored in ActiveDirectory or in a Unix system’s /etc/shadow file may look something like “bae60998ffe4923b131e3d6e4c19993e” (actually it won’t but we’ll gloss over that detail for now). The password cracker starts encoding 1 character passwords, moving onto all possible 2 character passwords, 3, etc.

Eventually he or she finds one that matches that “hash” at which point they will have the account’s password.

Dictionary Cracking

Brute force password cracking has historically been thought of as too computationally intensive to try, so people resorted to restricting the amount of passwords to search through by observing that most people use either simple words, or words made slightly more obscure through some method.

For example, the following are some passwords picked from a list of frequently found passwords (but before getting smug about your password being nowhere near as this simple, you may want to check first) :-

  • password
  • letmein
  • xxxxxxxx
  • qwerty
  • 123456

In addition, people often take a simple word like “monday” and make it more complex by replacing certain letters with digits – l33t speak – so “monday” becomes “m0nday”. There is no point to this at all – it is one of the most common algorithms for supplementing a dictionary. Similarly adding digits to the end of a word, etc.

Brute Force Cracking

The option of brute force cracking is the process of going through every single password combination and trying each one in turn. This would seem to be a very slow process, but computers are becoming quicker and quicker. For example, with a GPU password cracker, my workstation can tackle around 380 million passwords a second … and it is not an especially quick GPU!

As to how fast password cracking could be today, it is hard to say … some of the more interesting hardware out there doesn’t come with benchmarks, and there’s some guesswork involved. But it is probably safe to say that nothing quite comes up to the 100 billion password attempts a second mark … yet.

It is relatively easy to calculate the number of possible passwords for any particular length … take the size of the character set used in the password, which can usually be assumed to be 96 (all ASCII without the control set) and raise to the power of the length of the password.

Length Passwords Time (380M/s) Time (100 billion/s)
2 9216 <1s <1s
3 884736 <1s <1s
4 84934656 0.2s <1s
5 8153726976 23s <1s
6 782757789696 37m 8s
7 7.5E13 59h 12m
8 7.2E15 5725h 20h
9 6.9E17 62 years 1916h
10 6.6E19 6035 years 20 years
11 6.4E21 577,845 years 2028 years
12 6.1E23 55473145 years 193297 years

 

There are several points to learn from this table :-

  1. The numbers of passwords gets very large very quickly. But not quickly enough to keep up with password crackers.
  2. Any password of less than 7 characters is trivial to crack … even with relatively modest hardware.
  3. Any password of less than 9 characters is trivial to crack if you have access to a large network of machines to work with.
  4. If you want to be safe for another decade or so (and policies can last quite a while), you will probably want to pick 12 characters as the minimum password length.
  5. These are the times to search the whole password space … it is not necessary to search through every single possible password to find the password you are looking for. That password might be found in 1/10 of the maximum time, or 3/4 of the maximum time. As long as the person generating the password has not been spectacularly dumb, it will still take a significant proportion of the total time to find the password.

If you look at the different brute force password cracking software out there, it quickly becomes apparent that there are simplistic password crackers that attempt each password combination in turn, and there are more sophisticated password crackers that attempt to tackle the most likely password combinations first. They do this by looking at passwords consisting of words, parts of words, pronounceable sequences that could be words, etc.

However good they are, all they do is increase the likelihood of obtaining the password in less than the maximum time. And possibly not by very much; let’s be generous and suppose that an intelligent brute force password cracker can produce the password on average after processing 25% of the possible passwords rather than 50% of the possible passwords. So for example for a 10 character password, an intelligent brute force password grabber could be expected to find the password after 1,500 years rather than 3,000 years (with a worst case scenario of 6,000 years in either case) … helpful, but not enough to make password cracking practical for 10 character passwords.

Poor Passwords

Everyone is obsessed with telling everyone what makes a strong password, so there’s no need for me to do likewise. But here’s my thoughts on what makes a weak password :-

  • Contains a single word in any language however it may have been deformed.
  • Common sequences of digits (i.e. “31415926”) or letters (“qwerty”) … they are effectively the same as words and appear in dictionaries of words to try for dictionary attacks.
  • Where letters have been changed into digits is no stronger than the password with the letters would have been – the classic “monday” -> “m0nday”.
  • Appending simple digits or symbols.
  • Anything short; an otherwise strong password is weak if it is too short (less than 10 characters; preferably 12).

In fact the list of what makes a password weak is so long that it’s always a good idea to test how strong your password is. Preferably with a hacking tool; and not with one of those web forms where they probably don’t test too well to avoid irritating potential customers.

Passwords Suck!

Ha! Yes you’re right … passwords are now a pretty poor way of demonstrating identity. However whilst there are many alternatives, none are universal so until someone comes up with a suitable replacement we are kind of stuck with them.

Corporate Email Leaks – Measuring The Stupidity

 Computing, Security  No Responses »
Sep 092011
 

I was alerted to this by an article on The Register which points to the Godai Group‘s investigation into what happens when you register domains “close” to a reputable company and grab all the emails that happen to pop by. It is hardly a surprise to anyone who has run an email system, but you will get tons of email delivered caused by email address typos. Specifically Godai Group looked at a specific type of typo – accidentally leaving out a “.”. For example, one of the domains that the Godai Group picked up on was some-person@ca.ibm.com where “someone” has registered caibm.com (no dot) … whether or not that person is sniffing those emails cannot be known, but they could.

Again, to those who have run email systems it is no surprise to learn that some of the emails contain “interesting” information not limited to :-

  • Trade secrets
  • Business invoices
  • Personal information about employees
  • Usernames and passwords!
  • Network diagrams.

What is not mentioned is that those Fortune 500 companies almost certainly have policies in place prohibiting acts such as sending passwords and other sensitive information by email. But of course there is a description for someone who reads all of the corporate policies – someone who isn’t doing their job!

There is an interesting list of mitigations in the Godai Group report, but it could be a lot more extensive :-

  • When sending out an email to an address where the left hand side would be a valid internal address, flag the destination in your logs. Use that information to build up a list of domains for which you should check for valid internal addresses and freeze (hold in the queue) any messages that match. As an example, if mike.meredith@ca.ibm.com were a valid address you might want to freeze any emails addressed to mike.meredith@caibm.com.
  • Use your email logs to build up a database of domains that you send email to. This will allow you to identify similar domains that may be practicing so-called “doppleganger domains” that you may want to take some action against. You may think you can guess what the domains would be, but there is a lot to be said for hard evidence.
  • Perform content filtering on outgoing email, and build up a set of rules to catch emails containing patterns that match certain kinds of emails you do not want leaving your organisation – to begin with a pattern matching “password [is] XXXXXX”. This could take considerable effort to build, and there will always be the chance of a false positive so you will want a sensible warning message when emails matching the relevant content filter get caught – “Please check that this email does not contain confidential information; please check the recipient address, and if necessary re-phrase the email”.
  • Encourage the use of end-to-end encryption such as PGP. Plain encryption is not sufficient – “walled garden” email systems such as GroupWise support encryption for internal emails, but this is about external (even if it isn’t intentionally so) email which is not encrypted with such corporate email systems. In fact systems such as GroupWise may be considered dangerous in this context – it comes with the word encryption on the tin, and even allows you to “take back” emails that you have sent that you regret. These facilities encourage dangerous practices.
  • Education, education, education. But this will not accomplish much – not only are the people who really need to be educated not listening, but these problems are mistakes – both in terms of accidentally sending emails to the wrong address, and in terms of emailing information that should probably not be sent via email.
  • Lastly, and perhaps for amusement value, you could try persuading senior managers that the danger of them sending inappropriate information accidentally out to third parties via email is so great that it justifies setting up a process by which all their email sent to external address is manually reviewed to ensure that it is not an accidental release of internal information. Good luck on that one!

Naked Couple Exposed By Laptop Security Software

 Security  No Responses »
Aug 312011
 

I became aware of this story through an article on The Register – to summarise the facts, a woman bought what turned out to be a stolen laptop, and whilst using it to conduct a certain kind of webchat with her boyfriend, an employee of Absolute Software used previously installed software on the stolen laptop to ‘grab’ several items of data including screenshots of the webchat session.

Even if someone unintentionally using a stolen laptop cannot expect reasonable levels of privacy (and the Judge doesn’t believe that their privacy should have been breached), ordinary human decency should have been enough to exclude the naked pics. Anyone involved in the security world (including IT security) should be aware that anyone using a stolen laptop may well not be the person who stole the laptop and may be guilty of no more than stupidity by buying a stolen laptop.

Such stupidity deserves punishment, but the loss of the laptop is punishment enough – having naked pics of yourself passed around a bunch of geeks and then shown to the police is going just a little too far. And what about the boyfriend ? He didn’t have anything to do with the stolen laptop, so why were Absolute Software stealing naked pics of him?

Once you have a timestamp and a network address of the stolen laptop, that is sufficient in almost all cases to identify who to talk to about the laptop. Grabbing screenshots of a webcam chat is merely prurient voyeurism of the same order of magnitude as setting up network webcams in a shop changing room.

But there is more to this than just the salacious details of the kind of pictures captured. Who owns the data on that laptop ? Well all of the data on the laptop at the time it was stolen surely belongs to the owner of that laptop (unless of course they have been stealing data themselves!), but any data created since then does not. And that surely includes screenshots of what activities are shown on screen.

If Absolute Software had chosen to activate the webcam to grab pictures of the person using the laptop rather than grab screenshots, they would have been on slightly less shaky ground because they would then be creating data and not stealing data. And of course they would not have grabbed a naked pic of an entirely innocent man! However they should also have the decency to ensure that any images they grabbed didn’t contain an ‘unusual’ amount of skin exposed.

Plus of course by grabbing any sort of image from a webcam could put the employees of Absolute Software at risk of creating and viewing child porn – not everyone engaged in ‘adult’ webchats is necessarily over the age of consent!

Do OSX Users Need Anti-Virus Products?

 Computing, Security  No Responses »
Aug 192011
 

Revised answer: Yes

The longer answer gets a bit more involved. First of all, there is some level of protection built into OSX against malware called File Quarantine. There are limits to how much protection this provides compared with PC anti-virus and anti-malware products as it protects against known malware at the point where the malware is installed or run.

It is also limited by the frequency at which the OSX operating system is updated – OSX is typically updated once a week – unless you put off applying updates whereas a PC-style anti-virus product will typically update it’s virus definitions on an hourly basis. This would seem to make it totally inadequate, but OSX just doesn’t have as much malware as Windows.

There are a number of possible reasons for this including that OSX is inherently more secure and that OSX just doesn’t have enough of a market share for malware authors to bother with. The truth behind the lack of malware for OSX is only known to the malware authors, although it should be noted that OSX viruses do exist (as do Linux ones).

You could take the attitude that a flood of OSX malware is due any day now, and insist on running an anti-virus product in addition to the inbuilt protection OSX has. There are of course people warning that the flood of OSX malware is just around the corner, although they tend to be people connected to the anti-virus industry so are perhaps less than totally disinterested.

Of course if you have some seriously private data to protect, you should probably consider it. But most of us don’t work for the intelligence services, so can be a little less protected … for now. This of course can all change next month, next year, or sometime, so don’t take the word of this blog entry seriously especially if the date on it is a long time ago!

Of course now some time has passed, the situation has changed (with Flashback amongst others), so the answer is that yes you do need an anti-virus product. It is true that Apple has some built-in protection against Malware, but Apple is not an AV company and so they may well react too slowly to protect you.

Operating System Patches As Preventative Maintenance

 Computing, Security  No Responses »
Aug 132011
 

It is often the case that people are reluctant to apply operating system patches to servers for two core reasons :-

  1. Applying patches often means an interruption to service, and arranging an appropriate outage can sometimes be difficult.
  2. There is a risk in applying patches that they may break something that previously worked.

Both concerns are legitimate, but what is less often observed is that an unpatched server may appear to be working but to an extent is already broken – the patches are released to fix broken servers.

If we look at car maintenance, we are used to the idea that we take our cars for preventative maintenance – it is called a service. Almost everyone with a new car will routinely take it along at regular intervals for a service to reduce the risk that it will break unexpectedly. Those with older cars frequently accept that their car will unexpected break and they will have to cope with that when it occurs.

Or in other words we apply preventative maintenance to cars, deliberately taking them out of service (you can’t use a car when it is in the garage getting services) so as to exchange a scheduled period of unavailability for reducing the risk of an unexpected unavailability.

It should be the same for operating system patches.

 Older Entries  Newer Entries