Tuesday 6 November 2012

Passwords

I received an email some time ago asking whether I could add a facility to the Hex Edit Password dialog (see Operations -> Encryption -> Password...) to check the quality of the password entered.

I have seen web sites that check for various rules and I don't believe they are useful (except for a minimum length check as already provided in HexEdit).  I will explain this and how to create good passwords.  If you haven't the time to read the whole post, at least check out the summary at the end.

Password Validation Rules

First, a good password is not just one that is hard to break; it is important that it is easy to remember and type.  Second, whatever rules the password checker imposes affects the passwords that are chosen, which can itself create an avenue of attack.  Third, most of the time these rules don't ensure good passwords anyway.

I used to use a system for creating passwords and it was always really annoying when I tried a very good password but the web site prohibited it because of some rule, like it does not contain an uppercase letter or a digit.

Good passwords can fail these tests.  Moreover bad passwords can pass them.  You may have heard the story of one O'Reilly who worked in a high security (DOD) environment and for many years just used these passwords: "O'Reilly1", "O'Reilly2", ...  These passed all the rules (mixed case, punctuation, digits, etc) but were very definitely not good passwords.

The best approach is, as always, education.  The password creator should be aware of how passwords can be broken and what are good and bad password practices.

What Are Good Passwords?

There are several things to consider.  First and foremost the password must be hard to crack.  By far the best way to ensure this is to make sure the password is long enough.  I personally use passwords of at least 30 characters.  This may seem like too much typing, but it is often easier to type several words than to type a short jumble of random characters.

You probably know the commonly cited guidelines for passwords: that they should not be a word or name (in any language), involve your personal details such as car registration number, dog's name, SSN, etc.

What you are not told is that passwords should be easy to remember.  Passwords that are not easy to remember get written down and left in convenient places.

Another good practice is to avoid typing your password while anyone is watching, especially if they are holding a camera (or phone).  If you suspect that someone saw you type it and was trying to memorize it then you should change it immediately.

Difficult Passwords

I am currently doing some work contracting for a large company.  They have a lab of dozens of test systems and someone keeps creating passwords for these systems using an English word then mixing things up by making some letters uppercase and using Leet codes (eg E => 3, I => !, etc).  Here is an example:

  PaTh3t!c

There are so many things wrong with this approach.  When I am given such a password it can often take me many times to type it in correctly even when reading it.  I have seen other people just give up thinking they have been given the wrong characters.

Not only is it hard to type but it is also hard to remember.  After a while you remember how to physically type the password but forget the actual characters.  This can be a problem if you need to write the password down for another person (and you have to write these types of passwords down to have any chance of getting them right).

That's the other problem with this sort of password - it's so hard to remember that people have to write it down.  I am always finding little bits of paper with passwords written on them.  That's not good security at all.

Enforcement

I was a UNIX system administrator for many years and the one thing I learnt about passwords is that the worst approach is to try to force people to use good ones.

One policy that most operating systems provide is to force users to change their password regularly.  I really don't see the point in changing passwords more often than every year or so, as long as the password is a good one and you do not suspect that it has been compromised (in which case you should change it straight away).

Forcing people to think of a new password every few months, or less, means they will not try to think of a very good one.  Many Windows servers (ie, domain controllers) force monthly changes - I suspect this is some sort of default that someone at Microsoft thought was a good idea.  In this situation people invariably use the same password with slight variations.  An informal survey I conducted in an office with this policy showed that 100% of people just used the same password but added an incrementing number to the end of it.  Using this strategy some had reached large numbers (ie well over one hundred) meaning they effectively had been using the same password for more than a decade.

What I Do

I have used the same method of creating passwords since I was a UNIX system administrator and became aware of their importance (and how poor most people's passwords are).  I take a line from a song.  For example:

  Money, so they say, is the root of all evil today

Of course, now that this information is public it makes it easier for you to crack my passwords!  Even so it would take an enormous amount of time to try to crack my passwords by taking different consecutive groups of words from books and songs, even if you knew what books and songs I like.

For even more security, I also try to add some changes such as replacing "to" or "too" with 2, etc.  For example:

  $, so they say, = the root of all evil 2day

An added benefit is that the password is more likely to pass the password checking rules that require digits, punctuation characters, etc.

Summary

Here are the main points:
  • don't use passwords of one (or even a few) words in any language
  • don't use passwords related to public knowledge about yourself
  • use long passwords, if possible
  • don't use passwords that are hard to remember
  • don't force passwords to be changed too often (eg more than every 3 months)
  • don't write passwords down where they can be seen by unauthorized persons
  • don't type your password where visible to a person, camera or phone
  • change your password immediately if you think it may have been compromised

Monday 13 August 2012

Adding Windows 7 TaskBar Support


The new MFC (10) has built-in support for the Windows 7 TaskBar.  A lot of people are using Windows 7 now so I thought I better update HexEdit to take advantage of the new features.  In particular I wanted to add support for:
  1. thumbnails that appear when you hold the mouse over a TaskBar button
  2. for progress display when HexEdit is performing a long task
  3. for the task list that is shown when you right-click the taskbar button

I describe my success with these below but first look at some general issues I first had to solve.

MFC 10 and Windows 7

The first thing you need to use the Windows 7 TaskBar is an App Id.  I just added a resource string with ID of AFX_IDS_APP_ID and MFC found it automatically.  You can actually let MFC create the App ID from other resource strings but this way I could set it to exactly what I wanted (ECSoftware.HexEdit.Free.40).

The other things you need to do to get access to all the new features of MFC is to set WINVER to 0x0601.  (It was previously 0x0501.)  By itself this will allow MFC to take advantage of Windows 7.  (I have no idea why internally Windows 7 is actually 6.1)

However, setting WINVER to a value greater than 0x501 (version number for XP) may cause some things to not work if the software is to run under Windows XP.  And I still want it to run on XP!  For example, the Windows headers make the structure NONCLIENTMETRICS 4 bytes larger for Vista and later (WINVER >= 0x0600) so I check at run-time what version of Windows is running and adjust the size of the structure before passing it to SystemParametersInfo().

Furthermore, I still want the code to build under Visual Studio 2008 (MFC 9) since not everyone has VS2010.  So some of the code needs to be conditionally-compiled using the _MFC_VER macro.  (Of course if you build HexEdit with VS2008 then you will not get the new MFC 10 features.)

Thumbnails

Some sample MFC 10 applications support thumbnails so I thought it would be easy to add.  I eventually got it working (see screen shot) but it took me a while to work out how to add this to an existing MFC application.

Eventually, I worked out that I only had to call EnableMDITabbedGroups() at startup, magically even showing multiple thumbnails if there were multiple file open in HexEdit.  Moreover, there were extra features such as options for a close button on tabs, coloured tabs, etc.  Even better the new tab system added the ability to create vertical and horizontal tab groups and easily move windows between them (like MS first added to Visual Studio 2005).

There were some problems that I needed to work out though such as getting my tab context menus to work again.  This was actually quite easy and even continued to allow the context menu to be customizable (which is actually not a feature of any of the sample applications).  Also the tip window (which shows the associated file name when you hold the mouse over a tab) worked simply by setting an option.

It was not till much later that I found a big problem.  The Next Window command no longer worked.  This command has been in HexEdit from the start and allows you to cycle through all the open windows.  It is particularly useful in keystroke macros.  Internally there was now a tab "window" at the same level as the MDI windows meaning that my Windows API call to "get next window" code failed.  This was not too hard to fix once I understood the problem.

I also noticed that the Cascade/Tile etc options on the Window menu now do not do anything at all, so I disable them if the new MDI tabs are on.  (There is an option to use the old style tabs.)

Progress

Windows 7 has a cool feature where if a program is performing a long task it can show a green progress band as a background to the taskbar button.  This allows you to go and do something else when your program is busy but keep an eye on the progress by simply checking the taskbar button.

When working with large files HexEdit can take a long time to perform some operations, so this is the perfect application for the new Windows 7 TaskBar progress feature.  To add this change was trivial since HexEdit already supports a progress bar in the status bar.  It was a simple matter to add 4 lines to the function that already handles the progress display to get the Windows 7 progress to work.

Jump List

Encouraged by how easy the previous addition was I jumped straight into adding a custom jump list.  However, I soon found that this was no easy task at all.

First I should explain that the jump list is a list of options you see when you right-click on a TaskBar button - usually this is just a list of recently opened files.  The list is retained and available even when the software is not running.  By default MFC will give you a list of recently opened files, but I wanted three sections:

  • Recently Open Files
  • Commonly Opened Files
  • Favorites (indicated in HexEdit by adding to the Favorites category)


After a lot of reading and experimenting I could not work out how to get it to work.  There are some articles on using the new CJumpList class on MS various MS websites but they all contain mistakes or are incomplete.

None of the included MFC samples demonstrated the the CJumpList class and a search of the Internet reveal no complete samples except for the one at http://neuron.tuke.sk/~maria.vircik/apw/VS2010TrainingKit-pre%20tych%20co%20chcu%20vediet%20viac/Labs/Taskbar%20-%20MFC/Source/.  But there was no way to download the complete project for this apart from tediously extracting one file at a time.  I tried various FireFox and IE add-ons such as PimpFish but all were useless for just downloading the project files.

Eventually I managed to download all the files for the sample using the Expression Web "Import Site Wizard".

With the help of this project I believe I now know more about how jump lists work and the problems I previously encountered.  One of the problems is that for a file to be added to the jump list the software must be registered to be able to open that type of file.

Conclusion

As usual MFC makes some things really easy and some things really hard.  (Most of the time things are easy once you work out how to do them which itself can be hard.)

I have added the code for the thumbnails and progress and committed the changes to the SourceForge repository.  Unfortunately these changes were added after the release of HexEdit 4.0 but you can get them try them if you want to build HexEdit yourself.  Otherwise you will have to wait till I release HexEdit 4.1.