Two Factor Authentication for email

Very few people today are using two factor authentication for their email accounts. In fact, most people do not even know what it is. If you do know what two factor authentication is, odds are you are not aware if your email provider supports it. You are in luck if you use Google mail (gmail) or Yahoo mail because they both support two factor authentication. In this blog I describe why you need a second factor as well as a brief overview of what two factor authentication is and how it works on both Google and Yahoo.

Why bother?

You are probably asking yourself "why should I hassle with two factor authentication, it sounds complicated". I suggest you read this article on Wired.com that describes how the author, Mat Honan, was hacked. The end result of this epic hack on Mr. Honan was extremely destructive. The hackers obtained control of his Amazon, AppleID, gmail, and Twitter accounts. Using his AppleID They were able to remotely erase all of his data from his iPhone, iPad and his MacBook. They deleted his Google gmail account and took over his Twitter ID to tweet whatever messages they liked under his Twitter persona.

As the Wired article explains, this hack was based on Social Engineering. It involved the hackers physically calling customer support for both Amazon and Apple to provide information that allowed them to gain access to those accounts via their password reset mechanisms. Mr. Honan had "chained" these impacted accounts together and essentially they fell like dominoes after access was gained into the Amazon account.

Two factor authentication on his gmail account would not have stopped all of this destructive damage since Google was not involved in the mechanism used to gain access to Amazon and his AppleID. But, had he enabled two factor authentication on gmail it would have kept the hackers out of his Google account and would have indirectly protected his Twitter account. Unfortunately since both Amazon and Apple had a serious flaw in their security ecosystem Mr. Honan would still have likely lost the data on his iPhone, iPad and his MacBook.

There has been significant press lately about password strength. If you haven't already done so, read my blog on the LinkedIn password hack that managed to steal the password file for thousands of users. In that blog I describe why you should change your LinkedIn password after that attack and ensure that you have a strong password that is not shared with your email accounts. But that blog post is all about protecting, and having an effective, password. Two factor authentication takes security one step farther.

What is two factor Authentication?

Two factor authentication simply means you need two things to log into the account. Two factor authentication most often uses the following two "things" or factors:

1. Something you know (your password)
2. Something you have in your possession that nobody else has (usually a token of some kind)

Google and Yahoo both give you the option of having your phone act as the second factor, or the "thing" that you have. Basically once you log on with your normal password Google, and or Yahoo, will text you a numeric code that will be good only one time. This numeric code is that token that you "have". After the initial log in screen you will be presented with a screen that prompts you to enter the code that was sent to your phone via text message.

Using this second factor essentially means that even if your password has been compromised the hacker cannot access your account unless they have the token that has been sent to your phone. This protects your email account from the type of attack that happened to Mr. Honan, which effectively amounted to a password reset on the email account. It also protects you from other forms of security breaches in which your password has been compromised to an attacker such as the stolen password file incident that happened to LinkedIn.

Two factor authentication may seem intimidating, or an unnecessary hassle, but it really is not that intrusive once you have it setup for the first time. As you can see in the screen shot above Google gives you an option to "Trust this computer". If you check that box you will not need to enter the second factor again from that computer. Do not check that box on any shared computer. Yahoo has a similar feature that allows you to trust a computer and bypass the second factor verification step.

I urge everyone to take this threat seriously and incorporate two factor authentication on every account that they have it available for. Honestly, if your email provider does not offer it I would switch to one that does such as Google or Yahoo. Too much of our lives are dependent on our online accounts to not protect them properly. Think of how many accounts you have, such as your bank, credit cards, brokerage firms, etc., that have a password recovery option that sends a reset notification to your email account. For a hacker, obtaining access to that email account is the equivalent of gaining the keys to the kingdom. Protect it as best you can.

LinkedIn hack - change your email password

If you are sharing your email password with your linkedIn account, change them both now! Read on for more details.

Last week, on or about June 6th, LinkedIn reported a security breach in which 6.5 million passwords were stolen and posted to a Russian hackers website. The internet is abuzz with talk about this hack, including this article on Rapid7.com that lists the 30 most common passwords found in the 6.5 million entry list. According to Rapid7, "link" was the number one password found in the list followed by "1234" as the second most common. The sixth most common was "12345". These passwords are so easy to break they are not really passwords at all.

The file that was posted on the Russian website contained only SHA1 hash values of passwords alone, it did not contain the LinkedIn user id's. The password alone is of no real value unless you know the user id of the account it is associated with. Having said that, it is assumed the hackers have the user ID's for each password, they simply chose not to publish them. As stated above, the passwords are not stored in human readable form, they have been hashed using the SHA1 algorithm. The problem with the SHA1 algorithm, as that of any hash or encryption technique eventually, is it can be broken. SHA1 is easily cracked through various programs readily available to the public, but suffice it to say that the longer and more complicated your password the harder it is to crack.  

This hack should serve as a wake up call to everyone about using stronger passwords. I suggest using passwords no shorter than 8 in length with a mixture of letters, numbers and special characters. Also, avoid using words and phrases since they are easier to crack via brute force techniques.  Take the time to read these ten password tips posted by Rapid7.com even if you think you are savvy about security. 

It is not important if your password was included in the list of 6.5 million posted on the Russian hacker's site. At this time it is unknown if the hacker posted the entire list they have in their possession. For all we know the hacker simply chose to post the 6.5 million but managed to steal all the passwords from LinkedIn. Therefore you should take precautions and change your LinkedIn password regardless if you find yours in this 6.5 million or not.

Ensure Email Password is Unique

Many people use the same password for multiple accounts, including their email account. LinkedIn uses your email address as its user ID. If you had the same password for LinkedIn as you do for your email account it is imperative that you not only change your password on LinkedIn, but on your email account as well. 

You should never re-use a password across multiple websites, but we all know it is a common practice. It is of utmost importance, however, that your email account's password be unique. Many  sites have a "forgot my password" option that simply emails a reset link to the address on file. If the hacker has your email password they can simply access high value websites that use email addresses as the user ID and click the "I forgot my password" link. If the site in question sends a reset password link to your email account, the hacker can now change the password on the new site as well. Therefore if you were using the same password for LinkedIn and your email, you are in a position of extreme risk right now. Not only are your email and LinkedIn accounts at risk, but every account you have that uses your email address as the user ID is also at risk. 

Keeping your email password unique reduces the chances of it falling into the wrong hands via another compromised web site such as this LinkedIn hack. Make this change immediately regardless if you believe your password was included in the 6.5 million stolen from LinkedIn. 

What does KOATS mean?

Koch's Opinions Around Technology and Stuff
I am an Executive leader over a large software development division. Most of my blog posts will be focused on technology as it pertains to the software development industry. However I may occasionally blog on other "Stuff" that is completely unrelated to what I do for a living.

Opinions expressed on this blog are my own and do not reflect that of my employer or any other organization that I may be affiliated with.

Agile vs Self Fulfilling Prophecies

Most executives view agile development as simply a means to bring software to market faster than traditional methods such as waterfall. Executive understanding of how agile development works usually goes no deeper than "build it quicker". This article is not meant to bash executives. A C-suite executive should not need a deep understanding of the mechanics of agile methodologies, they have other aspects of running the company that they should be focused on. However, many agile projects fail because management at all levels do not effectively make the necessary cultural changes for agile to succeed. I believe effective agile development requires a cultural shift in the basic processes surrounding software development, and that shift must be supported from the executive C-suite all the way down to the team lead level.

The cultural shift that I am going to focus on today will be around release scope, estimation, and project planning expectations.

Self Fulfilling Prophecy of Waterfall 

A perceived advantage of a traditional waterfall development approach is that management knows what features are being developed (scope) as well as the corresponding estimates for those features (cost).  This information is plugged into a linear project plan along with the available resources and a date for project completion is yielded.

Under this linear waterfall approach there is a hidden incentive to pad the feature estimates to ensure the development team can hit their dates. These bloated estimates along with the linear project plan become a kind of self fulfilling prophecy. How often do you see waterfall projects completing early or delivering more scope than promised? It happens, but in my experience it is rare. Software development is like a gas, it will expand to fill its container and the project plan is the container. Management at all levels plan around this rigid linear timeline and as long as the milestones are being hit on time, all is well.

Working to a rigid project timeline is often embedded into the culture of the entire organization. There is little to no incentive to come in  early or deliver more scope than promised. The waterfall process can even restrict the addition of scope since once you hit the coding phase of the project all of the requirements and designs are thought to be completed.  You cannot easily add scope since the process does not usually allow for opening up requirements and designs once coding begins. Therefore culturally there are hidden pressures to simply push forward with the original plan unchanged. The culture teaches that the less change to the requirements and designs the better the project is going. This is almost always wrong.

Often times the best you can hope for with waterfall is an on time delivery of the promised scope. That sounds pretty good though doesn't it? The reality is that on time delivery of the promised scope is frequently not all that great. This linear method does not deliver the best results since mistakes in requirements or design are usually found too late to make meaningful revisions. You usually end up getting what you asked for, and often times you didn't ask for the right thing.

Agile Scope / Timeline / Cost Trap

An agile SDLC such as Scrum makes determining the exact scope and cost of a release much more difficult. Many techniques are used to "size" features that will go into each sprint, but it is very difficult to guarantee the exact features that will be included in a release. The idea of an iterative development process is to constantly refine and add to the application by learning from your mistakes during each iteration. Agile makes reaction to mistakes easier because you find them earlier in the life cycle. Therefore it is impossible to completely define what features will go into a release at the beginning of the project. This gives many executives a bad case of heartburn. They want to "know" what they are going to get, when they will get it, and what it will cost.

A common pitfall that I see in agile development is to succumb to the pressure of providing an exact scope and cost of a release at the beginning of a project. This pushes the development SDLC towards a more waterfall approach rather than iterative. Even if the development is done in iterative sprints a plan gets communicated that includes total scope and a final delivery date. Therefore reacting to unforeseen problems becomes nearly as difficult as it was under the waterfall approach.

Projects that have fallen into this detailed scope / timeline / cost trap tend to have less success with an agile methodology because they are not truly embracing the culture of agile development. Again, the biggest advantage of agile development is to catch mistakes early and continually refine your product by discovering what works in the small iterations. If all of the sprints are fully planned with scope at the beginning of a project, reacting to change can only happen by adding resources or elongating the project plan. This is counter to the goal of agile.

Under Promise and Over Deliver

I recommend all levels of management embrace a concept of under promising on features, but strive to over deliver. Instead of fully planning every feature on your wish list for the release, trim the feature list back to a bare minimum. Estimate the features as you would usually, i.e. with a large padding, and plan them into your sprints to provide a very high level project plan. Allow the team to select features from this "minimum" backlog but encourage the team to deliver more features in each sprint then what is planned. By doing this you eliminate the self fulfilling prophecy of a project plan.The team is motivated to deliver as many features as possible, vs. simply being "managed" to a rigid project plan.

I have found this strategy to work extremely well. Using this technique we are still able to deliver a high level plan complete with a delivery date, features (scope), and resources (cost) for all of executive management and our customers to plan around. Our success rate at delivering the minimum promised features on time is near 100%. But the big payoff is our ability to deliver more than what was promised, that is the over deliver part. The agile methodology along with this technique has allowed us to adapt to problems quickly and say "yes" to customers when they are asking for fixes to problems or additional scope. The frequency with which we can "squeeze" additional scope into the current release is extremely high and is measurable in our customer satisfaction results.

Professional software developers take pride in their work, I have encountered very few in my career that do not. Building the right culture in an organization and adopting good agile development methodologies will deliver great results. The key is to get the process out of the way of the development team and let them build software quickly. Once this is done right, the teams will take pride in over delivering on features and the results will show.