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.