Friday, 30 August 2013

A rant about QT for the Raspberry Pi and the danger of community projects

I am playing around with a Raspberry Pi. Actually, it is my friend's Pi but anyway, I want to write some programs on it. Python is all very well but I don't know anything about it really and the few things I've tried haven't failed in a very obvious manner so I wanted to look at something else.

I wondered about Qt (apparently pronounced cute) since it is a very well designed language based on C++. It compiles, it's fast, it's well featured etc. A quick look around and I found a site ( which has various wiki entries and one in particular looked like it might get me going:

It seems good. The basic story is that the packages aren't available yet from the repositories but you can compile it on a desktop and add it to a Pi image which you can then boot from. The first thing I noticed was the "do everything script". After downloading a few dependencies (like git and unzip) you run the script and it does everything needed to compile. Well, that failed. Couldn't find the init-repository script which is supposed to live in qt5 (and which is present if you follow the manual steps). So that was a bummer and I had to turn to the manual steps.

Some of the manual steps are slightly different in location/name from the script so I had to delete everything and start again, which wasn't so bad except I had just downloaded a 400Mb Pi image!

Anyway, I start the manual steps and there are various things that don't work. One of the git download links is broken (but they provide a mirror site to use fortunately) and then another step gets some source code from qt-project, rather than gitorious and this causes some code conflicts. I'm not sure why and since it wasn't mentioned in the instructions, I thought it might not be a problem. Carrying on, qtbase builds in about 25 minutes and then qtimageformats builds fine. I then got to qtjsbackend and it errored - it was the conflicted files from earlier and I then realised what had happened but then haven't gone back to find out why the conflict has occurred.

Without the super script, building all the modules is pretty time consuming since they have to be done one at a time in each respective directory but now, I've put it on hold because it's too messy.

Obviously this is some kind of open-source/community project and, of course, there is a lot of scope for these to do really well but they need leadership, direction and ownership. Often, these things start well but lack funds or personnel but what that means is that people like me who are pretty tech savvy cannot easily do something that is supposed to be easy and means that I'll probably skip Qt on the Pi altogether. If you are basing a set of beginner instructions on code that is not static, everytime a change is made to the code, the instructions need to be re-tested to avoid problems like this. Otherwise, download only static releases, which you know will work, and then you can test each time a major release is done. In the same way, having some specific commit that is not part of the core code is undesirable since it might be an accident waiting to happen and as with anything this low-level, the knock-on effect might be obvious or really subtle!

Rant over.

Do not rename Android resources in the Eclipse IDE

Eclipse IDE should be really good. It has loads of functionality and has been around long enough but it is still SOOO flaky. For instance, I ended up with two text fields in two different layouts that were called the same thing. This should be fine since the "view" is found in each activity and will only find the one in the current layout. However, you try changing the name of ONE of them in the Eclipse properties window and all hell breaks loose. Whether you select to "update references" or not, it will change all instances of the name in both layout files and both activity classes - not what you want.

I also noticed that if you type something into the properties box and press enter, when the update references dialog comes up, if you then change what you typed in to something else, it still uses the original text.

The best way to change them is to edit the layout XML directly and change the relevant ID. The resources will pick up the change and there will be no updating of references.

Other problems in Eclipse:

  1. Sometimes you cannot start debugging. I think if you kill the debugger too soon after starting it, it gets stuck and you have to restart the IDE.
  2. Updating things directly in the properties menu is basically a bad idea and causes all kinds of weird stuff to happen with focus.
  3. If you edit the strings resource XML (and possibly other files) and then change to the graphical layout and paste into the edit box, it actually pastes the code into the XML you were just editing which then might or might not create an error depending on what you pasted where!
  4. Callstacks during debugging are basically almost impossible to work out. Also, if exceptions occur when debugging, the debugger rarely takes you to the point where the exception occurs, but to some other weird place (that might be Android specific though)
  5. Attaching source code is a nightmare - I've basically given up.
The thing I dislike about projects like Eclipse is that in the rush to get more and more features, the quality suffers and you end up with something that you use because you kind of have to (for Android in my case) rather than because you really like it. Compare to Visual Studio which has got better and better and VERY rarely has any kind of stability problem. The actions are all obvious and the debugger fantastic.

Tuesday, 27 August 2013

How to secure your web applications

Securing web applications is not a 5 minute job but it also isn't rocket science. Below is a list of various ways in which you can secure your web applications from embarrassing data leaks or hacks. These are not in any particular order.

  • Use checklists so that you don't forget to do things. For instance, I have a checklist for provisioning a new server so I don't forget to do things like tweak the firewall or move a port number.
  • Use a modern operating system for your server. New flavours of Windows and Linux are much more secure than older versions out-of-the-box.
  • Understand, use and configure your firewall. This is one of the easiest ways to harden your server. If you are only a web server, close all ports except 80/443 (and whatever port you use for remote access)
  • Do not use standard ports for remote access. SSH and Remote Desktop can both be used on alternative ports. Simply moving ssh from 22 or RDP from 3389 can stop many people bothering trying to break in.
  • If you use ssh to remotely log in, disable root access and use public keys instead of passwords.
  • If you use RDP, ensure you are using the latest version and enable encryption.
  • Examine logs periodically to detect any attacks. Some attacks occur over many months so you don't have to read the logs every 5 minutes!
  • Do not give everyone in your company access to all your systems - many leaks occur because an unprivileged/un-trained user is fooled into accessing private data.
  • Never use a super admin account to connect your web app to your database. It is nice to know that even if someone were to hack your application, they still couldn't drop a table or select * from users!
  • If you have an admin interface to your system, keep it completely separate from the public web site. Separate application, separate web server, separate connection string, private network access only, full logging for any changes.
  • Keep your servers segregated and simple - the more complexity, the harder it is to manage and the harder it is to know you have secured a system properly. Also, a port opened for one service can be a backdoor into another if you are not careful.
  • Do not trust any input from your web application that comes from the user. Check it all - even in cases where input might be quite free-format, you can restrict the maximum length and check for a few really weird characters. If you really must take all the information, store it escaped in the database so it cannot be used to run code against your system. Have a framework that encourages this and makes it easy for your developers to get right.
  • Have a plan for when things go wrong. How quickly can you disable the system, reset passwords, inform your users etc?
  • Do not invent security. There are so many good libraries available that you will only do it badly. Do not invent hashing algorithms or insist on unusual password policies, "because you think it is better".
  • Do not use default usernames and passwords. In some cases, like Wordpress, admin is a default username so an attacker only has to try and brute-force a password. Changing admin to something else thwarts these kinds of attacks.
  • If your only security is obscurity, you will probably eventually come unstuck but having obscurity as well as security can be good to avoid giving attackers any useful information. Be careful not to advertise everything about your system security unless you have assessed the risk of doing so.
  • If at all possible, use SSL on your entire site and redirect all pages to ssl. Then enable strict http security on your web server and kiss goodbye to 99.9% of man-in-the-middle attacks.
  • Never, ever, ever, ever store passwords in plain text. In fact, consider hashing or encrypting other data like email addresses or street addresses too. A cracked password is mostly only useful with a matching email address.
  • Use the best-practice password techniques such as salted hashes using a strong hash algorithm like SHA512 or bcrypt. Modern brute-force machines can attempt billions of guesses a second! Also, consider blacklisting the dumbest 20 passwords such as "password123" but be wary of password policies that generally force people into using predictable passwords such as Canterbury1986. A general strength meter is better.
  • Be agile enough to be able to address security issues very quickly. If your software is 30 years old and would take 2 months to fix, you aren't going to make many friends if something happens. You also don't want to switch a system off as the only way of disabling the security vulnerability.
  • Things change so often, spend time researching new attack vectors, keep systems up to date, be open-minded with people whose opinions are different than yours.
  • Educate your users in a way that is not preaching. Security has become such a big issue but most users of systems have almost no idea of how web security works. 

How to style the FileUpload or make it look like you have!

There are many guides, workarounds and problems with trying to do something very common in HTML. It is the FileUpload control, a.k.a. the input type="file" element. The problem is that not only does each browser style the thing differently, you can't really change the look of it.

There are, of course, many applications where this isn't acceptable either functionally or from a design point-of-view so many people have asked whether they can style the control or just do something to make it look different. This is not an easy question to find an answer to because the answers vary from, "no you can't" to "yes you can but it's hard and not to be relied on". I believe this is largely a historical issue and that using jQuery, you can change the way the file upload behaves. In my instance, I am uploading an image but I want a button to select the file which looks like the other buttons on the page (and uses Bootstrap styles for this).

The (relevant) aspx markup looks like this:

<asp:FileUpload runat="server" ID="fileUpload" AllowMultiple="false" onchange="$.myFuncs2.submit()" />
<button id="btnChooseYourOwn" class="btn btn-success btn-large btn-block"><i class="icon-user icon-white"></i> Choose your own</button>

Which is the fileupload control running as a server control (so that I can access it from the code behind) and then a normal html button which works correctly with the bootstrap styles. The jQuery is also pretty straight-forward:

<script type="text/javascript">
(function ($)
      $('#btnChooseYourOwn').click(function (event)

The things to note are firstly, the file upload control is hidden by jQuery. If you set visible=false in the control, it will not be rendered on the page and cannot be interacted with by Javascript. Calling hide is the same as style="display: none;" The second thing to note is the use of event.preventDefault(). This is REALLY important, because if you don't prevent the default, the button will postback the page before you've even selected a file which, in my case, meant the page refreshed and reset back to the beginning again.

The function I call in onchange (myFuncs2.submit()) is just a function that displays a busy form and then calls $('form').submit() to cause the postback. At this point, the code behind can access the file upload control in the same way as normal.

You can probably do this in lots of other ways with other controls but hopefully this simple example shows that it is possible.

Why Microsoft (and so many others) still don't get it

If you run up a vanilla version of Windows Server and try to use Internet Explorer to download some additional software, you have most likely come across the disaster called, "Internet Explorer Enhanced Security Configuration". It might as well be called, "Internet Explorer Complete Functionality Block". You cannot use it in this mode for anything much. There are a few (Microsoft) sites trusted by default but you can't even download things like .Net Framework version 4 because one of the download URLs is not in the trusted list.

The thing that is annoying is either you click through hundreds of "blocked" popups and then have to add each site individually to the trusted sites list or otherwise turn off the popups and then wonder why certain websites just don't work.

In any company, with any system, but particular with software, there are various points where major flaws can be found. The initial designs, the pre-code analysis or user experience designs, you can spot things while implementing them, in system test, beta or just from user feedback. The fact that this disaster of software has somehow jumped through all these hoops means one of several things:
  1. The people who implemented it are incompetent and simply don't know what they're doing
  2. Some commercial person said the poor functionality was necessary for some other reason
  3. The processes for implementing software are very poor at MS
  4. Someone threw it in with something else, bypassing the correct processes
  5. MS don't ever listen to anyone else, whether beta groups, users or design experts
 It really annoys me because I think that the quality of a company is found in the day-to-day operations. If you run a cafe and the food is poor quality, it is not that there are "issues that need to be looked into", it is because the wrong people are in the wrong jobs. Extraordinary circumstances are more forgivable. If the cafe runs badly after a flood has occurred, we would accept that the owner might not know how to deal with the situation. Back to Microsoft and the software world, it is one thing to get something subtle wrong but if you write software, it should be spot on, more or less. It should work quickly, it should have a good interface, it should achieve a certain aim without negative impacts on other parts of the system. Come on MS, sort it out!

Friday, 23 August 2013

My first introduction to less.js with Bootstrap

What is Less?

Less, which you can find at is a great idea and very simple to understand. Imagine you are writing CSS and you want two things to be the same colour, normally you would do something like the following:

body { color: #f00; } a:link { color: #f00; }
So imagine if you want to change this colour? You would have to find and replace it: but that is not so bad. Imagine, however that you are trying to create a gradient from your colour:

.btn { background-image: linear-gradient(to bottom, #ff0000, #dd0000); }
The problem here is that if you change the red colour, you probably also need to change the other end of the gradient, this would be a different value to find/replace. Add in things like hover colours, visited links etc and the whole thing can be really hard. I was using Twitter Bootstrap ( and tried to make the button colours different from what I had downloaded. The buttons ended up looking terrible because I didn't know which colours to change and how.

Enter less (or rather "less css"). There are two really cool things you can do (and plenty of others you can find out about yourself). You can define variables which can be shared across definitions and you can define functions which can be applied to numbers/variables/colours etc (well, there are functions built-in, I assume you could add others if you really needed). So, example 1 above might be:
@textColour: #F00;
body { color: @textColour; } a:link { color: @textColour }
As you might imagine, when you process the less files, the variables are replaced by the values but it is more useful than that. You could also have things like:
@textSize: 18px;
h1 { font-size: @textSize * 2; }
h2{ font-size: @textSize * 1.8}
(note the fact that the variable has the "px" on the end but can still be multiplied) but you could also have:
@textSize: 18px;
@someMultiplier: 2;
h1 { font-size: @textSize * @someMultiplier; }
h2{ font-size: @textSize * 1.8}
That's cool. There is one other thing that is worth mentioning and that is functions, these allow you to do things to numbers or variables that, again, allow a top-level variable to be manipulated throughout your css. Here are some examples:
.btn { background-image: linear-gradient(to bottom, @textColour, darken(@textColour, 20%); }
 .btn { width: round(@buttonWidth / 3, 2); }
.special-window { height: cos(@windowWidth ; }

Downloading and compiling less

So, let us take Bootstrap for example. This uses less to compile the css so if we download the source for bootstrap and look in the less directory, you will notice there are about 30 .less files and each of these looks like css but with the additional functions and variables - they are obviously invalid as css until they have been processed. In the case of Bootstrap, the most important files are bootstrap.less which is the top level file and which is the only one that should be compiled and variables.less which contains all of the user-defined variables that are supposed to be modified.

 You will need a less compiler, I used WinLess, which is free. Start by downloading this and add the folder which contains all the less files from bootstrap and they will all be listed on the right-hand side. You might get errors since all the files will be ticked to compile by default but since bootstrap.less includes the other files, most of them will fail compilation. Don't make any changes initially, just un-tick all of the "compile" checkboxes on the right-hand list in WinLess except for bootstrap. Initially, untick the option to minify it and press compile. All things being equal, you should end up with bootstrap.css in the same directory as your less files and it takes less than a second to compile. You should do this before any changes just to make sure that the build process is working.

Once you have the compiler working, you can start to get to work. There are two things you might want to do. Firstly, by editing bootstrap.less, you can remove any modules that you are not using. For instance, navbar.less is quite big so if you are not using the navbar, you can comment out the include in bootstrap.less. As soon as you save any changes into this directory, WinLess will automatically rebuild the css file. After any changes, you may or may not want to include the file into a project just to check you haven't broken anything.

The second thing you will want to do is change the variables in the file variables.less. These are the only variables in Bootstrap that you are supposed to change (but you can change others, see later on) and again, once you save it, WinLess will automatically rebuild bootstrap.css.

More Customisations

Let's face it, there will be things that are hard-coded in bootstrap and other less files that are not derived from the variables and which won't be how you want them. You could override them in your own CSS but part of the fun of less is being able to specify these before generating the CSS so you don't have to override them. No doubt some people would argue this is bad for maintainability but Bootstrap 3.0 is already completely different than 2.3 so this won't be a problem for me!

For example, Bootstrap defines a modal dialog and the footer, where the buttons live, has a class called modal-footer. By default, this has a hard-coded background colour of some weird grey/biege, which is not what I want for my dialogs. I have two options, I need to modify modals.less (in this case) and change the css entry to either a different hard-coded value (and rebuild) or otherwise to define either a variable to put into variables.less which allows it to be customised or if I think it can be derived from an existing variable, such as body background colour, then I could use that variable instead. I could obviously alter any other variables such as darken the background colour by X percent or whatever. In my case, I also removed the border between the header, body and footer in the modal dialog so it looked like my design.

Obviously, you need to be more careful with hard-coded sizes. You might change a font size and it then conflicts with a different line-height or whatever but you can often tell by testing. I would also warn not to make too heavy changes to your less files otherwise they will become pretty tricky to maintain in their own right.

Using the files in your project

The easiest way to do this, like I described above, is to have WinLess running stand-alone and to copy the bootstrap.css into your project. Once you are ready to deploy, you can minify it also (and test it again!). There are, however options in different web scripting languages to generate css from less files dynamically by uploading all the less files to the web server and have some javascript compile these and store the results in cache. This was hard for me to do in .Net, especially since I already use a bundling tool for my scripts and css files. Also, I don't see a great advantage in this as opposed to just uploading the final css file itself but by all means check it out if you are interested in that.

Friday, 9 August 2013

Why PRISM etc. makes me really nervous

So many people have said recently, "if you haven't done anything wrong, you have nothing to worry about". What a load of garbage/trash/rubbish/hogwash. In the last couple of weeks, I have already heard of a few people who have felt the brush of the FBI when they didn't do anything wrong and today I have read the sad news of Lavabit deciding to close their company rather than comply with the shady dealings of the US government. Try telling the owners of their company that they have nothing to worry about.
For US companies, this is really bad news. Being compelled secretly to compromise your user's privacy and security is rather frightening. You trust the US government? Then you are foolish. What kind of government thinks it is acceptable to spy secretly on their own citizens (despite the fact they are only supposed to spy on foreign nationals!). Where is it OK that a Court, supposedly setup to provide a judicial oversight for the executive, is held in secret, whose proceedings are secret and in some cases, the people who are prosecuted either do not know they are being prosecuted or they are not privy to the evidence used against them - all in complete opposition to the idea of a Court - a public and defensible case against an individual by society. In what country is it OK for someone to search your apartment, access your emails, dig into your life, all without even telling you about it? Russia? China? The Banana republics? Nope. The USA, for many years the world leader in technology and where many IT companies are based.
Why am I nervous? I live in the UK so I am not bound by the Patriot Act and all the sordid laws that were somehow not only passed under George W Bush but have been upheld by Obama, no doubt to appease the paranoid law agencies in the US. Well, I use a Cloud provider (Microsoft) to host my service, a single-sign-on service. They have a data centre in Ireland but it is a US company so no doubt, if the US wanted information on one of my customers, MS could give them access to the Virtual Machines that host my data. They wouldn't bother approaching me because they would not be able to compel me to give them the information (and I would rather go to Court than provide it) but can MS access my servers? My web application? My database server? I would imagine so. I happen to encrypt most of the data I host in my web application (which many people don't) but the keys are obviously there somewhere, otherwise the web application would be useless. Can the US mine this information? The thing that makes me nervous is I have no way of knowing. Microsoft can say whatever they want but in reality, I know they are compelled not to reveal anything of the truth of the NSA access, although I doubt they would admit to it anyway since it looks bad if they allow a back door. The US government can say whatever they want about it only being for targeting people who are suspected terrorists but, no offence USA, your history of paranoia means you think everyone is a terrorist. What about the couple who searched for pressure cooker and backpack on the internet and got a visit from law enforcement? What about your contempt for Russia who have offered Edward Snowden asylum even though that is the normal course for anyone accused of political crimes. What about the way you have treated everyone who has told people some of what you get up to, revealing how much you have been lying to your houses of Senate and Congress even though they are supposed to have oversight? Basically, I have to assume my data is accessible by the NSA and if that is a problem, I have to do one of 3 things. Firstly, like Lavabit, I can close my company - not something I would like to do but probably something I would do if I was compelled to act like the US companies. Secondly, I could move everything in-house where I at least have control over access and at least I would know what data I have to share with the government because the request would have to come to me instead of my service provider or thirdly, I would have to try and be clever and set the system up to separate keys from data, split things across service providers and do all kinds of clever stuff to make it impossible for them to recreate my data without my help.
I'm not holding my breath for a solution though.

Thursday, 8 August 2013

Azure Cloud Service - "The credentials that were used to connect to...could not be used"

This was really annoying. I had setup RDP to connect to a cloud service but I kept getting an error trying to login. I even tried redeploying, changing the password and a load of similar things but no dice.
I then found out, when visiting the remote configuration page on the Azure portal, that the username "administrator" is not allowed to be used for RDP on Azure. This was confusing because this is the default username that Visual Studio gives to RDP when you configure it for the cloud service.
Anyway, I just had to change it to something else and it was fine.

Thursday, 1 August 2013

Password best practice and PasswordsCon13

I am shortly going to depart Las Vegas after 2 days and a slightly niche but incredibly important conference about passwords. Password Con only appeared on my radar relatively recently and since I was already heading from the UK to Canada, it was possible to travel a little further (in reality, twice as far!) and attend the small conference - conveniently timed to occur pre-DEFCON so that people would not have to make a special journey.
There were probably about 40-50 attendees but some of these are world-famous in the fields of password cracking. Some worked for businesses, others were self-employed/contractors, some appeared more academic and others, well they didn't seem to have much official capacity!
There were some very interesting talks about the very foundations of password theory - is there such a thing as a measure of a good password? Do corporate password policies really work? as well as more practical talks such as how to get the best out of choosing your "guesses" when using a cracker like hashcat.
To take a step back, if you are unfamiliar with passwords, ignoring the few sites that store the passwords in plain text (idiots), most sites perform a one-way function a.k.a. cryptographic hash or simply hash. The idea of this is that the password is no-longer readable and more importantly, you cannot feasibly compute what the original password is just from the hash. It's a bit like the number 670592745 which is easy to calculate from two factors but very hard to factorize back to what these two numbers are (they are 12345 and 54321). The arithmetic involved in these cryptographic hashes are similar in most cases, just MUCH, MUCH larger numbers. This is all great, in theory, but since the hash functions are necessarily public (so that people can check, test and implement them), rather than computing the password from the has, I can compute billions of hashes of known passwords and see if any of them match a password hash. When I say billions, some of these cracking machines can literally try billions of guesses per second.
Remember that most of the time, these machines are not trying to crack a single password specifically as much as many passwords from a big list. If I can crack 90% of a list of 100,000 hashed passwords then I can still use those to good effect (or bad effect). For this reason, even if my password is good, if most people's passwords are bad, then the damage is still done (but hopefully not to me).
Anyway, one of the things that became very obvious from the conference was that people 1) do not choose good passwords 2) Many sites do not adequately require and educate users on strong passwords 3) Even if a user is required to produce a strong password, it is almost always in one of a few standard patterns such as Uppercase, 7 x Lowercase and a number like Pineapple1976. The problem with these is that password crackers know these patterns, so they do not try to crack passwords starting at 0 and going up to ZZZZZZZZZZZ but select common patterns, which massively reduce the number of guesses required to find a lot of passwords. Just using something like Ulllllllnnnn can find 20% of most people's passwords in a few seconds!
So what's going on? It is clear that most sites are just doing their own thing because there is no-one really considered to be the authority on good passwords. Some sites will require that you do perhaps 3 out of 4 things things (upper case, numbers, symbols, lower case), others will require 1 or 2 of each type of "special characters". Some sites, shockingly allow the user to create 1 digit passwords! Although much of this is well meaning, many attempts to enforce policy result in users choosing bad passwords. If you have to change the password every 90 days, what do you think most people use as their password? xxxsummer, xxxautumn, xxxwinter etc. What happens if you require a capital and a number? Again Ulllllllnnnn. We actually find the same on PIN numbers that are very commonly 4 of the same digit or use the numbers 0-2!
Without a real understanding of how attackers hack passwords (which most people don't seem to have), you are trying to reinforce the front door while the attackers come into the back.
There were a couple of solutions. One had the idea that every leaked password became part of a blacklist on the basis that if the passwords were leaked, they would appear on an attacker's word list somewhere, which kind of makes sense but I can imagine would be very user-unfriendly. Another speaker stressed the importance of user education, even on the page where they have to choose a password - again, most of the top 10000 web sites don't do this. A colour-coded strength meter is better than a blunt policy, but again, what constitutes a good policy?
Password length, in general, is proportional to the strength of the password but if the password is still a dictionary word and a number (for instance), it is not a lot stronger than a shorter password since this is basic attack more. Using capitals and symbols is, again, better in a sense but if you swap your "a" for an @ sign in your password - they already know this and this is another attack vector. Passphrases can really help because they add length to a password but note that phrases from books are already known and can be easy to crack for this reason, as well as inserting something between words like a hyphen is fairly standard behaviour.
Remember that for the most part, the attacker will not usually want your password, just a number of passwords, so if you can make yours hard enough to crack, the attacker might give up. If you are a company or web site trying to create policy, you want everyone's password to be secure. So the following are bad things - if you can detect them, you could refuse them at account creation time - but remember that giving too much hassle to the user could lose you business:
  1. short passwords - quick to brute force. Recommend at least 9 characters.
  2. all lower case - quick to brute force
  3. common patterns - Ulllllllnnnn, Ullllllln etc.
  4. Contain a single word that has been altered somehow to make it look less "standard"  even when this word is slightly unusual/a place name etc.
  5. passwords that have appeared in the leaked lists - they will be in an attackers dictionary
  6. Leet speak - Using @ for a, 8 for b etc - these are already well known and will be used in brute-forcing attempts
  7. Passphrases from published works (including Bible book/chapter/verse), again much is already available to help crack these
  8. Passwords that contain social media searchable terms like names, parents, city where you live etc. One list for instance, contains all the first and last names of people from Facebook!
  9. Passwords that contain terms related to your business that can be easily derived from websites, LinkedIn profiles etc. This is more important for corporate passwords.
  10. Passwords used on multiple sites! Unless you share passwords only for weak/unimportant web sites, it only takes one crack to expose many of your accounts to hacking.
  11. Passwords that use keyboard patterns such as 1234, qwert, asdf etc.
So what are good passwords?
  1.  Long - but only if they do not break the above rules
  2. Random/Pseudo Random - These would only be crackable by a long-running brute force attack which is rarely carried out due to time constraints. If these are hard to remember (which they are) then use a password manager where possible.
  3. Passphrases that are unusual or guaranteed not to be found in any literature, such as, "My dog Ate a wonderful frisbee and had to visit the airport". Of course, the site has to allow long passwords and some, for bad reasons, do not.
  4. Typos - deliberately spelling things wrongly can sometimes help but various attack vectors attempt to mangle words so this is of limited help by itself - depending on the word.
  5. Using the first letters of a weird an unusual phrase - adding up to at least 10 characters or more preferably which makes, effectively, a random password that is easier to remember. For instance, the example in the passphrase in 3) could instead be entered as MdAawfahtvta.
  6. None standard patterns. For example, instead of Password123Password123, you could instead use pass8993WOrdp1a1s2s3w4o5r6d6
There are, of course, more important aspects to password security than the password itself. For instance, most of these problems start by a site being breached. Why does this happen? Very basic schoolboy errors in web application implementation - to me, it should almost be a crime to not carry out basic checking on your site. The following types of controls should be minimum:
  1. Never, never, never use a database admin account to connect from your web application to the database. Don't even do this during development, you create the chance to deploy it this way accidentally.
  2. Always, always, always sanitise input from the user. Every input text field should have some form of validation, such as alphanumeric, max length etc. Work on what is allowed, not what isn't.
  3. Do your homework, do you know what characters an email can contain? Do you have a correct regular expression to validate this? Do you know if you are using a simple regular expression which might not correctly handle edge cases?
  4. Use a more modern hash algorithm or something like bcrypt or scrypt which are purposefully slow. These do not prevent attackers cracking passwords but can slow them down noticeably.
  5. NEVER create your own hash functions or variations on existing functions. At best, you will add no additional security, at worst, you will either make it much weaker or allow the attacker to optimise their attack while the defender incurs a lot of CPU/Memory overhead.
  6. Just because you use a framework like PHP, Ruby or .Net does not mean that their functions are necessarily good or appropriate. PHP have only just included password hashing functions in the framework, the previous options were either weak or complicated.
  7. If possible, access your database using stored procedures and a user account that only has execute privilege. This way, even a cracked website can do little harm.
  8. Try not to re-invent things that already exist. If you write your own password policy, for instance, you could miss something important or make a simple coding error that would make it ineffective.
  9. If your site is important, pay someone to test/verify it/pen test it independently. Don't expect everything for cheap or free.
  10. Have an easy way to report security failures and respond to them quickly and effectively, your reputation is important and even major failures can be survived if your response is appropriate.
  11. Make sure you have the means to reset passwords/contact users etc so that a breach can be notified quickly.
If anyone has any other ideas, add them to the comments below, I have just written this off the top of my head and might well have missed something.