I came across this interesting metric called "Cyclomatic complexity" at work today. It is measurement of how complex a function is in terms of the logical branches it has.

The formal definition as in Wikipedia is quite mathematical and not in tune with the thinking of the like minded people visiting my blog.

A far less and simple definition can be found at this code project article which says to calculate this metric:

• Start with 1 for a straight path through the routine.
• Add 1 for each of the following keywords or their equivalent: if, while, repeat, for, and, or.
• Add 1 for each case in a switch statement.

There is another defintion as seen in Ncover's site which says

The cyclomatic complexity value is the maximum number of test cases needed to get 100% branch coverage, and the minimum number of test cases needed to exercise every path through a method, so it provides a good way to tell how well-tested a method is.

Happy cyclomatting.//

I never knew that we have so many software development methods that exist until I read some stuff today. If you had asked me yesterday I would have said:

1. Waterfall ---- thats what I learnt in my first few months at TCS.

2. Spiral --- the diagram when I first saw looked confusing, but thats what I do mostly these days.

3. Extreme programming --- I had spent some time with a start up. Definitely productive with so less management interference. You were almost always the boss but of an extremely small team and which is sometimes just you.

The others which are interesting to know and are formal methods are:

1. Structured Programming Development -- everything is structured, disciplined.

2. Cleanroom -- strong focus towards defect prevention. Quality is though design+coding and not testing.

3. Iterative development -- I dont know how this is different from the Spiral method.

4. Prototyping --- do prototyping, go to user, re-prototype until acceptable. Sounds like RnD project to me.

5. Modified Prototype Model --- Like web-page maintenance. Start simple, keep on modifying based on user needs.

6. Rapid Application Development --- No time, just do it.

7. Joint Analysis Development --- Developers work closely with end-users to develop the software.

8. Exploratory model --- Requirements not known initially, but lets start the project and we will see what is needed.

That makes eleven Software Development models. Woow!

Happy Modelling.//

This post was written keeping in mind the Exceptions in C++, but may equally apply to other languages.

I have more than N times had the tough call to decide whether to throw an exception or to return an error from a new function that I write. Frankly speaking I have used the return statement more often than throwing an exception. Exception had always appeared an unnecessary overhead to me and appeared to make my code look less graceful.

However of late I have been working on developing a library where APIs are exposed for others to use. Throwing an exception has started making a lot of sense to me when I am developing a library for which I have no control on how my functions would be called. Even here I seem to often ask myself : Is throwing an exception the right thing or returning an error code the more right thing? Below are a list of guidelines that I try to follow to come to that decision:

Throw an exception knowing that if the caller does not catch it, the application will terminate. In other words, throw exceptions for grave errors. Returning an error code does not terminate the application if the caller does not handle it. In other words, use exceptions for critical errors that cannot be ignored. Use error codes if the error isn't severe and may be ignored. This fact is a good yardstick to decide if you want to return or to throw an exception.

If you have an error throw it, if you have a state, return it. But isn’t an error just another state? Yes and No. My take is that if you think that the caller has done a grave error against the functionality, throw an exception. As an example, the caller gave a corrupted .mp3 file to the function PlayMusic(char* file), I would throw an exception if I can detect the corruption. If I detect that I have no read permission of the file, I may return an error. If the file does not exists, it may do either of it. So it appears to me that we have to live in a mixed world and use what makes sense to us and what makes your code more graceful.

In constructors, exceptions are the only way to point a finger to the caller. You cannot return an error code from a constructor; you only have the option of throwing an exception. You can also use another member variable to indicate that the object is not properly initialized, but the later is just a workaround for not utilizing the power of the language.

If your function has the possibility to return more than one set of error values, use exceptions. In other words, if you really want the user of your function to debug what went wrong through an exception of a user-defined type, you should prefer exception over error codes. Even if you think that the caller cannot correct the reason for the exception, it not a reason for not throwing an exception.

If it makes sense make a single ApplicationException that can hold reasons for several exceptions rather than making a FooException, a DoException, a NoDataException, a InvalidDataExceptions, etc. Do this if it makes life easier and more sense to the user of your function and not to you. In other words, design exception classes on a subsystem by subsystem basis.

Though there are no hard rules, I have one to share: Don't treat exceptions as a glorified form of return statement and don’t use it for your fancy or to demonstrate your OO programming skills.

Don’t be carried away by those first paragraphs in books that tell you the advantages of using exceptions over if-then-else. They promise low bug-rate, improved product quality, less testing time, less maintenance cost. You may end up getting the exact opposite results if you don’t use your own judgment.

Tip:
Talking to somebody in your team who hates exceptions followed by somebody who love exceptions may help.

Links:
-- What should I throw?
-- What does Google's C++ style guide have to say about Exceptions?

Happy Throwing.//

Powered By ReadTheWords.com

In yesterday's post, we discussed about the pitfalls of sending plain text password during a user's login process into a website. We concluded that to prevent Bob from doing a man-in-the-middle attack, we need to achieve the following while posting the login form:

-- We should not send the password or any reversible derivation of Alice's password.
-- Whatever we send as replacement of the password should be different every time.
-- And yet the server should be able to authenticate Alice.

Consider the following steps:
a. The server gave the browser a number, k, via a java script variable. This random number is stored in the server.
b. User types in his password in the form along with his username.
c. The MD5 sum of the password, p is calculated as H(p). It is then appended to the key, k. Lets call it H(p)+k.
d. The MD5 sum of (H(p)+k) is calculated. as H(H(p)+k). This is what is then sent to the server.
e. The server has the MD5 sum of the password, H(p) and the key, k. It can derive its own version of H(H(p)+k). If the two matches then the user is authenticated.

Lets analyze the above steps now. In step (c) we had H(p)+k. Why could this be not sent instead of doing another md5 sum. As data is transferred in plain text, Bob who is sitting in the n/w saw that the server gave the key, k. He also saw that H(p)+k was transmitted to the server. He could now get H(p). Later he makes a request to server for a new key, k~ and sends back H(p)+k~ to authenticate himself and he suceeds.

Lets try to now see if Bob can make use of what we finally transmitted in step (d). We transmitted H(H(p)+k). Bob has this and k. Bob cannot practically get H(p) from what we transmitted -- because an MD5 sum is a one way transformation. Moreover we transmitted is only of one time use because of k. Bob just cant make use of all the data he has to authenticate himself successfully unless he knows the user's password p.

There is a flaw however in this approach, and it in in the key, k itself. The server has no way of knowing to whom(for which user's login) the key, k was sent to. So it needs to keep k constant and not random. If k is constant then H(H(p)+k) which is actually sent over the n/w is constant for a given user. And Bob can use it. The server at best can keep k constant for a short period of time and there after start using a new key, k~. This gives a small window for Bob to authenticate himself. So Bob needs to be on his toes to break in. But the sad part is that Bob will be on his toes, because he is Bob.

If however the server knew that Alice is going o login, then it can create a new random key every time and keep it beside the Alice's credential in the DB. The server will only know that Alice is trying to login if the browser sent a request with only the username first. This means a two stage authentication. Here are the steps again.

1. Alice opens www.example.com/login.php in his browser. She gets a form asking just the username. Alice submits form. (Bob sees that Alice is trying to log in).
2. Server generates a random key,k, stores in in DB against Alice's row in the DD, and sends back a page with key, k as a javascript variable. (Bob also see the key k). This page asks Alice to enter her password.
3. Alice types in the password in the form. Browser calculates hash of p, H(p). It then adds k to it, i.e., H(p)+k. Then it rehashes it as H(H(p)+k). When Alice submits the form, H(H(p)+k) along with username "Alice" is sent to server. (Bob sees that H(H(p)+k) as a stream of data).
4. Server calculates it own version of H(H(p)+k) and verifies it with the incoming data. Alice is authenticated if they match.

This time however Bob cant make use of anything to authenticate himself as Alice to the server.

The pain here is that the login is a two stage formality. Alice first enters just her username and fills her password in the second form. Is this acceptable?

There is one remote scenario where it would fail. Alice should not just enter her username and then go to another computer and restart the session again, enter her username and come back to her first computer and enter her password. Authentication would fail. This is definitely acceptable.

All these just because you could not make your server run a SSL version of the web server.

In all the discussion above I have used the term md5 sum instead of using the term "hash" which is more commonly used to describe such an issue. A more advanced version of such a hash is SHA1 sum which is gaining popularity.

Resources:
Javascript implementation of MD5 checksum.
Digest::MD5 - Perl interface to the MD5 Algorithm.
MD5sum in PHP.


Happy login.//

Powered By ReadTheWords.com

Do you remember the last time you typed in a password into a site? Was it https:// ? If it was not and simple http:// then your password had most probably traveled in plain text over the network which mean Bob can read it. The risk multiplies when you do so from a public Wi-Fi network which is not uncommon these days. Yahoo and Gmail both have an https:// login page and you should always use such options whenever available.

Why do then web masters not switch to https:// everywhere? The answers are plentiful. Some of them are :

1. https:// web server requires more CPU processing at the server and not because setting up an SSL web server is tough.
2. Maintaining a legitimate server certificate costs money and having a self signed certificate causes an irritating pop up to users.
3. Many webmaster just don't see the value of encrypted traffic unless their site involves credit cards.

Most websites dont store the password in plain text in their db (some do which is really really really bad). Most of them store it in en encrypted form which is not reversible. One easy way to find out is to ask for a password reset on that site. If they give you your original password, it means they store it. If they send a new password or a link which gives

you a new random password, then there are chances that they dont store their password in their db. What they actually do is store a checksum of the password. During the authentication(login) phase the checksum is recalculated again from the user entered password. If the check-sums match you are through. MD5 checksum is the most commonly used mechanism in the internet today for website login authentication -- atleast for most sites using LAMP.

One of the cool thing that the web master can do is calculate the MD5 sum via javascript in the client's browser and send the checksum into the server. That way Bob does not get to see Alice's password traveling in plain text. But this does not prevent Bob to use the checksum to authenticate while Alice is away. Its just a HTTP post request. Bob can build one with the user name and the checksum and send that HTTP POST request to the server and get himself authenticated (remember that Bob is an expert programmer also among other things).

The only probable advantages in this approach is : Alice's plain text password does not flow on the wire. Many people including Alice maintain a password pattern. Example, if Alice's gmail password is Alice##Gmail, there is a fair amount of chance that you can guess Alice's Ebay or Paypal password. Tranmitting the hash of the password can save Alice from Bob trying to hack into Paypal or Ebay. This is because it is difficult to reverse engineer the password from a checksum like MD5.

Lets digress a bit and see how webmasters can make life difficult for Bob. Webmasters can make it difficult for Bob if the name of the login field and password field are not "name" and "password" respectively. A form with the line

<input type="text"  name="login" size="18"/>
<input type="password"  name="password" size="18"/>

is easier to track via Bob's favourite automated tool than

<input type="text"  name="45634734" size="18"/>
<input type="password"  name="87658375" size="18"/>

Those numbers "45634734" and "87658375" are something that is time dependent and generated at the server randomly, but must remain constant for a short period of time.

Two advantages in this approach are:

1. It becomes difficult for automated sniffer tools which pick up usernames and password from network traffic as they operate on predefined signatures. The idea is to make your HTTP POST message look very different than what a normal login request would look like.

2. Since those numbers will remain constant in the server for a short period of time, it would require Bob to try to authenticate himself immediately. Not that its impossible, but we are tightening the noose. But Bob knows how to automate this step. Adding a CAPTCHA can make life difficult for Bob.(Are you thinking of the article you recnetly read about how CAPTCHA has been broken. If so, we are talking of a very important website and for such sites, having an SSL server is a must). The last statement was just to keep this discussion in track.

However in all these approaches, the biggest weakness is that the Alice's password is sent over the n/w in one form or the other. What needs to be achived is:

-- We should not send the password or any reversible derivation of Alice's password.
-- Whatever we send as replacement of the password should be different every time.
-- And yet the server should be able to authenticate Alice.


Continued in my next blog post ......