Considerations for Securing Log-in?

Someone was asking us about what factors to consider in order to develop a “secure” log-in component. Off the top of my head, I could think of the following rules of thumb that you should honour, assuming 1-factor security:

1. You really should communicate over SSL

2. You should also never transfer any credentials in the query string (neither username, nor password, nor any token of any sort)

3. Also, make sure that the password is never stored in plain text in your data repositories – you must always store its hash generated using a one-way hashing function. Being one way means that you can never go back the other way and retrieve the plain text password from the hash.

This means that you can never retrieve the password from the hash, so in order to verify it, you must take the newly provided password and hash that too, then compare both hashes to verify if they are identical. You can never do the comparison based on the plain-text of the password itself.

This is important because it illimates the risk that the admin will be able to find out what the plain-text password is by reversing the encryption function. From an algorithmic perspective, it is not acceptable to just “rely on the trustworthiness of the administrator”

4. At the same time, it is recommended that you use a “salt” to encrypt the password, or some other strong form of encryption.

I’m sure there may be others, but I can’t think of any more now – What else should we look for? 

Pandora’s Box: The Egyptian Software Outsourcing Industry Today – Risks & Trends

The Egyptian Software Outsourcing Industry is a relatively young industry. It is a very dynamic, growing, and changing industry. I believe that this year is going to mark a watershed period in the outsourcing industry across the world, and especially in Egypt. There are many tidal waves that are coming our way, and we’d better be prepared for them, otherwise brace yourself and take a deep breath, we may be about to sink.

The purpose behind these series of articles is to expose some of these upcoming risks and then open up the discussion for proposed mitigations or solutions.

 Some of these risks are very critical and we can’t afford to stand back and observe – we must be actively leading the market, on the forefront, trying out new innovative ways of survival.

Let’s start by looking at some of the changes in the world market one by one. This post will focus on local talent.

Competition: Attract and Retain me or die.

The wonderful thing about software is that you don’t need to be very resource-rich in order to participate in the revolution. All you need is some ingenuity and you can get very promising results. There are several garage-based developers who have toppled many industry giants in the world of software.

 This is the same reason why you get a lot of noise being made in places like Egypt, India and the Ukraine in the software field, where other industries cannot pick up momentum.

 This is an advantageous situation for many; in these countries Software Enterprises get a chance to thrive and compete on a global scale delivering surprisingly high quality software with minimal cost. Export your services, and you get international clients who are happy with your quality and thrilled at your cost model.

 This has created a multi-billion dollar software industry which has accelerated rapidly in many parts of the world; both in terms of adoption of the outsourcing model as well as establishing new outsourcing workshops.

Recently the competition around the world has become enormous, and it is now more and more a question of how you differentiate yourself.

With that introduction out of the way, it is time to recognize the real champion behing this multi-billion dollar revolution. The Software Developer. The Human Capital, Your core talent. Regardless of what they do exactly, if they write the code, test it, deploy it, support it, “infrastructure-it”, architect it, etc. This is the most important asset of any of these competing  companies.

Your building facilities are next to worthless, your computing hardware loses value faster than you can spell “depreciate”. The one most important factor is us. You are the driver of this revolution.

 Employers know this, and that is why there is always a tugging exercise happening behind the scenes to compete for resources – to compete for us. Employers are always battling to attract more resources, and to keep them by offering the highest possible package they can afford without compromising their cost model.

Competing for the Bottom Line

It is elementary that the reason why we may or may not be competitive is a factor of the quality of the software we deliver, and its price. This year in Egypt, our biggest threats are coming in the area of elevated packages that are being raised so high that they are going to blow the ceiling and threaten our cost model.

 Don’t get me wrong; I’m not advocating that we get under paid by any stretch – I am just voicing a loud concern about our long term sustainability.

 It has always been the case that IT services offered in a non-IT firm can sometimes get better compensated as distinguished and valuable inputs to the machinery required to operate in their specific market vertical. For example the telco market is sometimes able to better compensate IT individuals than a software firm because of many reasons – including the fact that they have much larger margins, and the fact that the bulk of their cost is not derived from these IT people – i.e. they can afford  to better compensate them without damaging their bottom line; their business model.

Say Hello

At the end of this first post, I will just conclude by asking people to welcome the new risks we are facing – the first step we need to do is to get acquainted with them, say hi, and then go back home and think about our next move.

This year we are welcoming a cash-rich telco operator in the market that is causing noticable waves in salary structures across the country.

As if that was not enough, there are strong rumours of two gigantic Indian Software companies that are setting up shop in Egypt with promised contract valued at several million dollars. The Huge Indian companies bring processes and operating models that are proven to work and will give them a significant advantage relative to local companies who don’t have similar experience.

This means more demand for your software person, with pretty much the same supply!

 So is that our risk I hear you ask?

No.

Our risk is not merely that the salary structures are rising, and our hourly rates will follow them. Our risk is that this is going to happen so quickly that our deliverable quality will never be able to rise high enough to catch up with it. This is what is going to threaten your long term sustainability, and your pay check next year.

 Unless, we are aware of these risks and act accordingly…

See you next post.

Catastrophic Development: Reflections on the Union Carbide Industrial Disaster in Bhopal

Background

This year marks the 22nd anniversary of the world’s most catastrophic industrial disaster at the Union Carbide plant in the Indian city of Bhopal. On the morning of December the 3rd, 1984, 40 tonnes of Toxic heavier-than-air Methyl-Isocyanate (MIC) gas were accidentally released to spread across the surrounding roads and streets in Bhopal in the Indian state of Madhya Pradesh.

Thousands of people’s lives were abruptly terminated. The entire city’s transportation system was brought to a standstill, worsening the situation further, as many people were trampled while trying to flee.

People woke up to find their bodies burning, their family suffocating, and ran out to the streets to escape, only to find that those before them who had been blinded by the gasses and were aimlessly rushing in unknown directions eventually collapsed to the asphyxiation of the mortifying gasses and died, lining the streets in piles.

The effect of the gasses rolling out of the holding tank eventually injured from 150,000 to more than half a million people, and the death toll reached 15,000 people. Many sources confirm that contamination is still present in the region.

The damage from the gasses ranged from respiratory diseases, blindness and skin diseases, to reproductive problems.

QuoteOut:

• “There were thousands of bodies. There were bodies everywhere. And people were dying all round.”
  • Mohammad Owais, a volunteer at Hamidia Hospital, Bhopal, India

BoxOut:

The Causes of the World’s Greatest Industrial Disaster

In the investigations that followed this disaster, the catastrophe was attributed to many factors, tragically, all of which did not have to happen, and were completely preventable. These included:

• Lack of preparation for this sort of problem. No action plans were available for emergencies, and no contingency plans available to mitigate risks.
• Reports issued months before the disaster predicting something of this magnitude would happen, and they were summarily ignored and never presented to senior management.
• An Audible External alarm that was sounded to warn residents in the early morning hours, was quickly silenced – to avoid causing panic to residents.
• The gas burning exhaust tower that allows gases to burn off before escaping into the air was inoperational, waiting to be serviced.
• Doctors and Hospitals were not informed of the risks of MIC inhalation, and of its treatment methods – so they simply administered cough medicine and eyedrops to their patients.

QuoteOut:

• “We have to travel at least two kilometres to get clean water… My health is so bad that it prevents me from carrying the water I need from there.”
  • Hasina Bi of Atal Ayub Nagar, a neighbourhood in Bhopal near the plant

How is this related to what I do?

You might think that this is very remote from your daily line of work. This is a problem in a different industry, a chemical plant, so far away from me, in an Indian city whose name I can’t pronounce, by a company I’ve never heard of before.

That’s the problem. The entire statement above is false. The difference in industry is immaterial, Union Carbide’s now infamous name has become immortalized down the industrial hall of shame. There are people who rally against Union Carbide, and its new owner Dow Chemical every year on this anniversary, all over the world. India in this case represents exactly what Egypt does in terms of attractive labour-cost and more fundamentally, lack of attention to audits, risk awareness, reviews and safety measures.

QuoteOut:

• One reason, according to the Canadian Law Professor Jamie Cassels, who has written a book on Bhopal, is “the unwillingness of the industrialised countries to forego the competitive advantages offered by the less developed world.”

Unlike a Natural Disaster (like an earthquake, volcano, tsunami or the like), Industrial Disasters are caused by mankind. The fateful truth is that more often than not, they are caused by varying degrees of negligence and ignorance.

Let’s look at some of the root causes of this calamity listed above, and examine them with an eye critical of behavioural traits in our human culture. In our society there is a tendency to ignore “safety nets”, measures taken to ensure completely smooth delivery are often thought of as being a luxury – if you can just barely get it through the deadline, then you’re a genius. Remember what happened a few weeks ago when the fire alarm sounded 10 times in the company? How did we react? Do we know why it did that?

There is an obvious trade-off between risks-assumed versus quality-expected in every human endeavour. If you are driving a donkey-cart on a side road, some may say its okay not to have to tightly pack your payload on to the donkey cart. What’s the worst thing that could happen if you drop something? You go back and get it!

If you are on the ring road, and the car in front of you all of a sudden drops a traveling suit case in the middle of your lane, you probably won’t live long enough to explain to the other car’s driver how dangerous it is to travel without securing your payload first.

The reality is, if the project fails, the client will never appreciate the shortcuts you took to save them the extra mile at their expense when in reality the client’s safety is being jeopardized. Sometimes people think that developing software in a Professional Services firm such as ITWorx is a relatively safe enterprise – and that no bug (or fault) can hurt anyone. On the contrary, we are conditioned to think that avoiding “extra” safety procedures pays off.

Here’s what you could typically hear the root causes to the disaster being dismissed:

• Lack of preparation for this sort of problem: “Yaa Raagel, this thing happened only once in India, Kabar Dimaghak!”
• Reports issued months before the disaster predicting something of this magnitude would happen: “Maho this is the way we’ve always done business, would you just shut up and go on with your work?”
• An Audible External alarm that was sounded to warn residents in the early morning hours, was quickly silenced – to avoid causing panic to residents: “Why make such a big fuss about something? How bad could it be anyway? What does an early warning mean by the way?”
• The gas burning exhaust tower that allows gases to burn off before escaping into the air was inoperational, waiting to be serviced: “It’s okay, maho nothing usually happens anyway – we rarely use it!”
• Doctors and Hospitals were not informed of the risks of MIC inhalation: “Da Kalam? You want me to go around scaring the Doctors about something they don’t need to know about? Even if I tell them, they won’t understand. Just shut up.”

Software faults can actually be fatal. Software Bugs can kill you, they can squander all your money – wasting millions and millions of it – they can put you at great disadvantages in the institutions that rely on systems full of them, they can waster your time, or merely inconvenience you.

The point is, the larger the project you are undertaking, the higher the risks. Sometimes taking shortcuts is not an option.

Big Boxout: Am I a Catastrophic Developer?

• This section asks several thought provoking questions about the way we conduct business in the computer science arena and how that will influence our delivery standards. Take a moment to think of each of these questions carefully.
  • Do you manage transparently?
    • Do you keep “sensitive”, “important”, “privileged” or “interesting” information to yourself first before sharing it? Do you often conceal this information unwillingly due to time constraints? Do you make an active effort to pro-actively share such important information periodically with your team? Do you hold yourself accountable on how transparent you are? Do you teach your team what you know, or do you just do the important parts yourself, because it takes less time?

      Do you manage from an ivory tower not really knowing what your team is doing because you’re too senior?

    Do you Version your deliverables?

    • If I asked you which version of your software was installed at the client’s location, would you be able to give me an exact number? Would you be able to reproduce that numbered version from your source repository to match the version at the client’s byte for byte? Would you be able to guarantee that for every version “number” there would be one and only one actual version associated with it? Can you tell the difference between each minor feature adjustment or bug-fix? Are your release documents updated to reflect changes?

    Do you conduct full traceability on all dimensions of your project?

    • Do you think they are a waste of time? Do you know that they are the only way to scientifically prove the completeness of your deliverable? Do you know that without traceability you have no way to securely guarantee scope completion?

    Do you Unit Test your work?

    • Do you use a good unit-testing check-list? Do you know that ITWorx has a recommended unit-testing check-list? Do you know that the developer is the one who is supposed to run these tests before submitting their work for testing? Do you just deploy your code to the testing server the minute you think its finished and leave it those testers to find out if it works or not – because that’s what they’re job is anyway?

    Do you conduct proper, full audits?

    • Do you intentionally mislead auditors or give them half-truths? Do you conduct Mechanical-Audits? Just asking questions without searching for hidden truths? Do you understand why the auditor visits you? Or do you hate their guts? If the auditor asks you a seemingly useless question do you pray that they disappear or do you raise your concern with them?

    Do you communicate properly within your team?

    • Do you pause after you make changes and ask yourself “which stakeholders does this change impact?” and then notify them? Or do you often wait until one day a group of team mates starts screaming and yelling about fundamental changes that have been done behind their back?

    Do you give your Risk Management plan due dilligence? Do you keep it updated?

    • Is your risk management plan just composed of “Volcanos cannot be mitigated”? Do you periodically re-visit your Risk Management Plan to make sure that nothing new has surfaced? To make sure that you are increasingly ready for risks coming up on your radar?

    Do you re-invent or re-use the wheel?

    • Do you jump into developing first without looking to see if what you need has already been done? Do you seek to learn from the experiences of your pre-decessors? Do you ask yourself what others have done before you? Or do you prefer implementing from scratch? Every single time? Do you broadcast good ideas that you discover? Do you institutionalize reform and change? Do you contribute to re-use repositories?

      Do you keep the improvements to yourself, and end up being the only one to benefit from your lessons-learned?

    Do you review your work?

    • Do you peer-review your designs? Do you check that your packages actually install? Are spelling mistakes important to you?

    Have you considered emergency procedures?

    • Do you have plans to support your clients with high severity issues? Do you not think about this because it is not mandated explicitly by anyone?

Boxout: We’re Doomed – I can’t do anything about these problems!

• If you’ve read some of the questions in the “Am I a Catastrophic Developer” panel, you probably guessed what the right answer we are hinting at was. How can I avoid disastrous development given cost-constraints?
  • Here is a simple recipe to managing risks in a way that safe-guards you against catastrophic development:
  1. Take a minute to think of this – and make your own decision. Ask yourself: “Do I want to be part of a project that will produce a potentially catastrophic development?”. Set your own standards.
  2. When you make your decision – make a point of taking time out every day – give yourself a minute to think of any major risks you may have glossed over today. Is there any one that your work today may impact negatively, either today or in the future?
  3. Make sure you are always current – new risks and new solutions are identified every day in our dynamic industry. It is your prerogative to make sure you are always current with technology.
  4. Learn how to make balanced decisions to deliver efficient risk management, and if you don’t know how to handle a specific situation, don’t just leave it – share the risk transparently with those responsible in your team and take educated decisions, even if you need to consult the client. Your experience will only grow by observing and asking mentors to give you their experience too.
  5. Finally if you are asked to blindly work on Impossible Situations where catastrophes are imminent without transparently communicating links to all stakeholders (including the end client), then make your own judgment call – are you going to be a part of the catastrophe, or the mitigation?

Epilogue

The Obligation to Fight Catastrophic Development is everyone’s responsibility. If you don’t, you bear on your shoulders the responsibility of potentially bringing harm on to others, perhaps very grave harm. The irony is that you can be a very hard worker, and yet by ignoring certain precautions, you can still be a catastrophic developer. One can only hope that we are always alert and aware of this fact. Our only defense against this is to continue to seek to be armed with knowledge, alertness and integrity.

Boxout: References

For further information, please browse these links out. Please note that the content in these pages can be deeply disturbing.

Bhopal Disaster:

• http://encyclopedia.thefreedictionary.com/Bhopal+disaster Wiki About the disaster
• http://www.bhopal.com/ Dow Chemical-Union Carbide Official Site
• http://web.amnesty.org/pages/ec-bhopal-eng – Amnesty International
• http://news.bbc.co.uk/2/hi/programmes/bhopal/default.stm – BBC News Site.

Software Related Disasters:

http://news.bbc.co.uk/2/hi/science/nature/4381840.stm

This post was originally published in ITWorx Insite (April 2007).