Brave Tech World

October 2, 2006

     There are hundreds of Web 2.0 companies out there providing similar service. There is probably a few doing similar things to Sampa, and some might be exposing an API for developers to use it.

    Nowadays, there is this notion that companies should expose their database and business logic for people to be able to mashup, import, export, integrate, connect, extend, etc.

    I think that is great, and at Sampa we do Mashups with a dozen service already.

    Investing the time and effort into making a Sampa API is far down the list. Customers are not asking, and we are not sure what the real value would be at this point.

    Here is an example: there is about two dozen (or more) sites for you to upload your picture (Sampa, Flickr, Photobucket, Smugmug, etc.). Almost all of the new Web 2.0 companies that are doing photo storage provide an API, and I ask myself why? Do they really think that people are desperate to implement their API instead of Flickr?

    My point is that APIs for Startup are not that valuable and cost too much resources, unless, you own some type of exclusive content (like Kayak) or you provide a unique service (like Riya).

    Once we have a couple hundred thousand active users on Sampa and dozens clamoring for an API we might add that to the list of features to be stack-ranked against all the features that the other users are asking for.

     This reminds me of a post on the blog Creating Passionate Users about how companies tend to focus on their competitors and not on their customers, and that is bad.

October 9, 2006

    I just came across this post on the official C# FAQ blog on MSDN. It shows a very simple way of computing an MD5 out of a string. As the post says:

"...It is a common practice to store passwords in database using a hash ..."

    And they go showing an example of a function that has this signature:

public string CalculateMD5Hash(string input)

    Can you spot the security vulnerability here?

    Here is the problem, although a Hash is a one-way algorithm, the same string will always result on the same MD5, and that is good and bad. It is good because you can test passwords to see if the hash that they generate are the same as the one stored on the database, it is bad because somebody can use a dictionary or brute force attack to figure out 60-70% of the passwords on the database in just a couple of hours.

   "Emily" will always be encoded as "D8EA48BC5A82A9FD6B80F70DD51FC30C". So, somebody with a decent size dictionary of names, cities, and other words will be able to figure out a lot of the passwords.

    But these people that understand security are very smart (smarter than me for sure) and they came up with a thing called a "salt".

    A salt is a just a random sequence that helps to generate a different MD5 for each password. This means that if user #127 uses the password "Emily" and user #538 also use the password "Emily", each will have a different MD5 if they had different salts.

   I wrote about what makes a good authentication database schema on another post just two months ago.

   Now, the problem with the function from the MSDN blog is that it doesn't tell you how to use it right, which is the case with must security related documents on MSDN, and, by consequence why so many developers write so crappy code in regards to security.

How you do it right...

    First, you create a database schema (or save an XML file, or whatever) that contains at least the following information:

• UserId, Username, Email and whatever other information you need
• PasswordHash: Either a char(32) or a byte(16)
• PasswordSalt: An integer (int32) will suffice.

    Second, add this function somewhere on your code:

static public MD5 md5 = MD5.Create();

static public string ComputePasswordHash(string password, int salt)

{

   byte[] inputBytes = Encoding.UTF8.GetBytes(password + salt.ToString());

   byte[] hash;

   lock(md5)

   {

      hash = md5.ComputeHash(inputBytes);

   }

   StringBuilder sb = new StringBuilder(32);

   for(int i = 0; i < hash.Length; i++)

   {

      sb.Append(hash[i].ToString("X2"));

   }

   return sb.ToString();

}

    Notice that this function creates a single static MD5 constructor and make sure that only one thread can use it at a time -- this is faster, trust me (or measure it yourself).

    Third, when a user creates an account (or update his password) you generate a random integer for his salt, which, BTW, could be a hash of his username combined with his IP address, and then you compute the hash, like this:

public void SetUserPassword(int userId, string password)

{

   int salt = DateTime.Now.Ticks % 0xFFFFFFFF;

   string hash = ComputePasswordHash(password, salt);

   // Save the 'salt' and 'hash' to the DB

}

    Fourth, every time a user tries to sign to your system, you check to see if the password is a match on the database:

public bool IsCorrectPassword(int userId, string password)

{

   int salt;

   string hash;

   // Load the 'salt' and 'hash' to the DB

   string hash2 = ComputePasswordHash(password, salt);

   return String.Compare(hash, hash2, true);

}

    This might look more complicated than the simple example from MSDN (and it is), but it is the only correct way of using MD5 Hashes to store passwords.

    Using the MSDN example somebody could do a brute force attack on the database and figure out most of the passwords, and would just take a couple of hours to do it. If you use salt, you make the computational cost hundreds of thousands of times harder, which means that instead of a couple of hours to crack your database we are talking about decades!

    And just to makes matters a tad more interesting, I usually use a double salt. This is, there is a fixed string in the code that I add to the computation of the hash so that if somebody gets my database it also needs to get the source code (or the binary) to make his/her life less miserable when cracking the hashes.

October 14, 2006

   From: http://developer.yahoo.com/maps/mapsTerms.html

f. YOU SHALL NOT:

...

(vi) use the Yahoo! Maps APIs with location information that is less than 6 hours old and derived from a GPS device or any other location sensing device;

... 

    I guess they don't want people to build GPS-based applications that constanly calls the Yahoo API to plot the points on a map, which is fair because an automated system like that could overwhelm Yahoo's servers.

    Now, how about your super-modern digital camera with GPS and WiFi, where you take a picture and instanly upload it to Flickr? I guess that picture can't appear on the Flickr's map until 6 hours later.

    Oh, stupid me, Flickr is owned by Yahoo, so I guess they have an exception.

    At Sampa I have a dual-monitor setup with two Dells 20in LCD which gives me a 3200x1200 working area, but at home I have only one monitor, also a 20-inch Dell LCD.

    Once you go dual-mon is hard to work on a setup with a single monitor.

    You might have saw Apple's self serving study where it says that a 30-inch monitor increases productivity over a 17-inch monitor. A lot of people might laugh at it, but I know it to be true.

    Now I have to keep alt-tabbing between VS, MSDN, Outlook, IE and Firefox. Argh!

October 16, 2006

    I disagreed with Guy Kawasaki many times, but this one hits home today:

...

4) Forget the ”proven“ team. Proven teams are over-rated--especially when most people define proven teams as people who worked for a billion dollar company for the past ten years. These folks are accustomed to a certain lifestyle, and it's not the bootstrapping lifestyle. Hire young, cheap, and hungry people. People with fast chips, but not necessarily a fully functional instruction set. Once you achieve significant cash flow, you can hire adult supervision. Until then, hire what you can afford and make them into great employees.

...

 

 

Week 43 of 2006

Week 44 of 2006