Jun 30

Solving partitionkey problems using Windows Azure tables that runs locally fine but errors “One of the request inputs is out of range” when published

I’ve made a quite simple WCF (Windows Communications Foundation) project using Windows Azure Tables with a DateTime string in the partitionkey. And it really works fine locally. Even if I skip the storage emulator, and really put the data in Azure Tables it still works fine. The WCF service is run locally on my development computer.

But as soon as I publish the WCF service to Windows Azure I get the error:

One of the request inputs is out of range

Quite strange, because the WCF (using the real Azure Tables) works great, storing the information correctly to the Table storage, which is proved by the Azure Storage Explorer. So: What is the difference between my development computer and Windows Azure?

I used the DateTime.UtcNow.ToString() to populate the partitionkey. This is because I wanted to balance the load over time when reading the rows.  My developer computer is localized NL-nl, that uses a dash ‘-‘ to separate day-month-year. Because I use this function as part of the partitionkey, there is a ‘-‘ inserted when I run the service locally. But the Windows Azure computer uses a month/day/year notation, so when running on Windows Azure the function produces a ‘/’ as part of the partitionkey.

And the ‘/’ is not allowed as part of the partitionkey.

So the solution is to comply with the Windows Azure Table Service Data Model naming convention and leave out the ‘/’ as part of the partiotionkey.

Please comment if this was usefull to you.



Jun 09

Linkedin hack: bad security policy unneccesarily exposed password of linkedin users

This week about 1,5 million password were published that where stolen out of the LinkedIn database. While every system has its weakness and no system is full proof, this exposure of passwords is COMPLETELY unnecessary.

Why you should never store passwords?
Linkedin stores all the password in a database. They indeed n the password, but in a weak manner. But even if you do encrypt them, there is still an encryption key that can be stolen. You still are vulnerable to theft of this key, once you store password.

How to prevent stolen passwords?
There is a simple solution: DON’T STORE ANY PASSWORDS

But how can you authenticate if you don’t have the password?
Instead of storing the complete (encrypted) password, you should store a hash of the password. By choosing a good algorithm it is impossible to retrieve the password simple because the information is not there !!

Simple, once you know IT