Isolated corporate security is inappropriate

In my previous post I mentioned Mat Honan, the Wired author whose digital life was destroyed by hackers within an hour.  How they did it has big implications for how companies and corporate security think about and implement security and their security policies.

Using Amazon to hack Apple to hack Google to hack Twitter

The entire article about Mat’s experience is very interesting, and details exactly how quickly and easily the hackers were able to take over his account.  Mat actually talked with the hackers and they explained how they did it: Continue reading Isolated corporate security is inappropriate

Secure your e-mail with two-factor authentication

Particularly relevant after my discussion of Canadian banking password policies, Microsoft is adding two-factor authentication to Hotmail,, the Windows Store, and other Microsoft services.  Articles such as “Two-factor authentication finally heading to Microsoft Accounts” make it obvious that this is overdue (my emphasis).  Unfortunately it’s not released to the public yet, but if you use any of these Microsoft services then I recommend you use it when it becomes available.

Use two-factor authentication for your e-mail!

In fact, I STRONGLY recommend you use two-factor authentication for your e-mail account wherever you have e-mail.

The reason is simple:  Continue reading Secure your e-mail with two-factor authentication

Target-state banking password policies

Somebody commented to me the other day that a bank’s website wasn’t secure because of their poor password policies, and I’m sorry I gave that impression.  I can’t speak to their security overall, because I don’t know their network topology and a hundred other things about how they’ve implemented their systems and how they’ve trained their personal. Continue reading Target-state banking password policies

Application design considerations

For some time now I’ve been meaning to write down rough list of things I consider in my role as enterprise architect for a project on either a new or existing system.  Often in the early stages of a project I will be the project architect, and then in the later stages of the project I will transition to become the lead developer. Thus, I have included a high-level application design consideration list and a more detailed lower level application design consideration list.  In my experience, being aware of the lower-level design considerations has always helped inform the high-level solution design considerations. Continue reading Application design considerations

Poor-quality passwords at a major Canadian bank

At TD-Canada Trust I just noticed their passwords must conform to the following ridiculous password policies:

  • be 5 to 8 characters in length
  • not contain spaces or special characters (e.g. #, &, @)

Now I have no inside knowledge of what TD is using to store their passwords, and I have no inside knowledge of what hardware and software they are employing to protect their network. However, this password policy is both strange, and incredibly scary. A 5 to 8 character password is not very strong, and mandating that it NOT contain special characters further weakens the strength of the password! The rest of the internet is trying to make passwords stronger, and this major Canadian bank is forcing its customers to use weak passwords!

These are VERY weak passwords

With only a to Z and 0-9 there are 26*2 + 10 = 62 possible characters for each position, which means there are 62^8 = 218,340,105,584,896 possible TD EasyWeb passwords. This sounds like a large number, but it’s really not. Here’s why…

Let us assume that this bank is using IBM WebSEAL – which is very popular with banks and insurance companies – and incredibly it only supports SHA1 for password hashing (in version 6.1 at least).  This is a VERY poor choice for mathematically protecting passwords.

A free and easily accessible tool such as Hashcat can try 2,136,000,000 SHA1 password combinations a second on a Windows 7 x64 bit computer with a single AMD graphics card.  This number goes up when you add more of these graphics cards to your computer.

So if we take the total possible number of passwords and divide them by the speed at which Hashcat can crack those passwords, we get: 102,219 seconds, or 28 hours! We can reverse-engineer every possible hashed SHA1 8-character password in a little over a day with an average computer.  Of course, if we could get the list of user-ID/passwords for their website then we wouldn’t need to crack every single possible password, we could just crack the ones that are actually used.

So if we can steal get the log-in credentials for TD EasyWeb then we could easily reverse engineer these passwords and log in to EasyWeb.  That’s a pretty big if, but it’s not impossible.

Of course, you probably use your bank password at other websites as well – it’s supposed to be secure right?  So if attackers can get this password where else can they now get access to?

The recent TD Denial of Service

What makes this low-strength password policy scary is that on Friday TD Bank was recently hit by a “targeted” distributed denial of service  attack. A denial of service attack is when attackers use hundreds of computers around the internet to bombard a website with requests, overloading the webservers and preventing legitimate users of the website can’t get through.  The bank has said that “the security breach did not compromise clients’ accounts or personal data.”

However, attackers frequently use denial of service attacks to camouflage
data breach attacks. In December of 2012 the US Treasury Department issued a statement saying:

A DDoS attack seeks to deny Internet access to bank services by directing waves of Internet-based traffic from compromised computers to the bank. …  Fraudsters also use DDoS attacks to distract bank personnel and technical resources while they gain unauthorized remote access to a customer’s account and commit fraud through Automated Clearing House (ACH) and wire transfers (account takeover).

So while the bank has indicated that no data was lost, if this DDOS was actually camouflage for a data breach it may be some time before the nature of the breach surfaces.


Again, I have no inside knowledge of TD’s systems, security measures, password storage mechanism, etc. I am just a concerned computer security person writing about a possibility.  It is my sincere hope that TD uses incredibly strong password hashing algorithms combined with secure password salts. I also hope that this DDoS attack was launched by a bunch of script-kiddies or a group like Izz ad-Din al-Qassam Cyber Fighters that are just looking to disrupt things for the bank for a while.

Nevertheless, if you bank with TD EasyWeb then I recommend that you change EasyWeb your password, and any other websites using that same password. If during the DDoS the attackers were able to compromise TD’s systems and steal their credential data (user IDs and passwords) then changing your password now could help protect your bank account. If no data was stolen, you probably haven’t changed your banking password in a while anyway and changing it now to something new is a good idea anyway. 🙂


PS.  If you’re looking to improve your passwords in general, then I strongly recommend you check out KeyPass password manager.  It’s free and can create very strong and very long passwords – and then it remembers them for you.  🙂