Powered By ReadTheWords.com
A good C++ coding standard is one which tell you when you may break the rule. For that you need to un-satisfy the justification of the recommendation. In other words, one quality of a good coding standard is one which gives a justification for every item.

Secondly, it should contain language specific suggestions and guidelines (stuff which are legal, but best avoided outside your college/school).

C++ Coding Standard by Todd Hoff is the best I have ever read. Where was it all the time?

Happing coding.//

Powered By ReadTheWords.com
Shuva learned the following stuff by accident just yesterday:

1. If your braces and alignment in a block of code is not proper, the do a Ctrl-X, Ctrl-V (cut the code block and paste back). Voila!!

2. Pressing F-12 is equivalent to "Go to Definition".

Happy programming.//

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 ......

Talking of the goodness of the goto statement in C programming is often considered evil. People would just rubbish you the moment you say “We can use a goto statement to do this .....”. The common cited usage of goto is to implement a break out of more than one level of for or while. I think I have realized another good situation to use the goto statement from my own experience.

Take this example:

int function() {
	SOME_STRUCT someStruct;
	char* file = NULL;
	char* folder = NULL;
	char* drive = NULL;
	HANLDE *ptr = NULL;

	ptr = AtleastDoThat(file, folder, drive, & someStruct));
	if (ptr == NULL) {
		CloseHandle(ptr);
		return 1;
	}

	file = new char[100];
	if (!DoSomething(ptr, file)) {
		CloseHandle(ptr);
		delete[] file;
		return 1;
	}

	folder = new char[100];
	if (!DoSomethingElse(ptr, file, folder)) {
		CloseHandle(ptr);
		delete[] file;
		delete[] folder;
		return 1;
	}

	drive = new drive[100];
	if (!AtleastDoThis(ptr, drive, file, folder)) {
		CloseHandle(ptr);
		delete[] file;
		delete[] folder;
		delete[] drive;
		return 1;
	}

	return 0;
}

In the above example we have a bunch of local variables which gets allocted progressively and its this function’s responsibility to clean before exit. There can be multiple exit points and you have to make sure to clean all of those variables that you have allocated some resource. In real time, this function will look very dirty and not as clean as simple new and delete[]. The problems with this code are:

1. As this function adds more code, there is a risk that the programmer will miss to clean up as he has to put the cleanup code at multiple places.
2. Readability is bad.
3. The reader has to un-necessary go through all the cleanup code while reading the actual logic. Attention is diverted.

Now take a look at this:

int function() {
	SOME_STRUCT someStruct;
	char* file = NULL;
	char* folder = NULL;
	char* drive = NULL;
	HANDLE *ptr = NULL;

	ptr = AtleastDoThat(file, folder, drive, & someStruct));
	if (ptr == NULL) {
		goto error;
	}

	file = new char[100];
	if (!DoSomething(ptr, file)) {
	}

	folder = new char[100];
	if (!DoSomethingElse(ptr, file, folder)) {
		goto error;
	}

	drive = new drive[100];
	if (!AtleastDoThis(ptr, drive, file, folder)) {
		goto error;
	}

	return 0;

error:
	ptr?CloseHandle(ptr):NULL;
	file?delete[] file:NULL;
	folder?delete[] folder:NULL;
	drive?delete[] drive:NULL;
	return 1;
}

The idea of discouraging goto is that people tend to misuse it by not writing elegant conditional jumps thereby reducing readability. In this case I find it increases readability. Many programmers use this technique. Thoughts?

Happy branching.//