Musings of a curious mind

Security considerations for storing passwords in a database

2012-02-16T12:25:00.000-08:00

It is a common practice to store user names and passwords in a database. This can be done in the following ways

Store it in clear text
Encrypt and store
Store a hash of the password instead of the password itself

Lets examine the pros and cons of all of the above methods.

Store it in clear text

Anyone having access to the database can read the passwords and has an option to misuse it. It is not recommended to store passwords in clear text.

Encrypt and store

This is better than storing in clear text as it is not human readable. The security however depends on the encryption algorithm used. If a hacker manages to crack the encryption algorithm then all the passwords are compromised. Use a strong encryption algorithm with a salt to minimize the threat. Almost all encryption algorithms can be cracked, but most of them will take more than a year for a super computer. Considering a probability that the user will change the password once in a year, it becomes impossible to crack. Consider having a password policy where you use a fairly long password (min 5 characters with special characters, upper and lower case alphabets and numbers) which will require many combinations before it can be tried.

Store a hash of the password instead of the password itself

This is one of the best ways to store the passwords. In fact, you actually don't store the password but its hash. The problem with this approach is that you cannot recover the password. Every time the user forgets his password you will have to generate a new password and send it to him using which he can set a new password. The good thing about this approach is that even if a hacker manages to crack one password rest are secured. This will give you a lead time to handle the security breach. These hashes are also prone to dictionary attacks.

One more option that comes to my mind is to store an encrypted hash which gives a double layer of security. Now the choice actually depends on the security requirements of your application. Advanced security may also hamper the performance. It is a fine balance that an architect has to make.

Custom Authentication and Authorization in WCF

2012-02-16T12:06:00.000-08:00

Recently I had to implement a restful web service with a custom token based security for it. The following is a strategy for a typical token based security

Client calls the authenticate operation passing the user name and password
The web service authenticates the clients credentials and issues a token with some expiry time
The client will then pass this token to each subsequent call to the web service
Before every call the web service will verify the token before allowing access to the operation

There are two things that needs to be done, authentication and authorization. WCF provides two classes for doing this, ServiceAuthenticationManager and ServiceAuthorizationManager. We can create our own custom authentication and authorization classes by inheriting from these classes respectively. These classes can then be configured in the web.config for use in our web service. In the next post I will demonstrate how this can be done.

Keep watching.

Avoid over engineering

2012-02-16T11:49:00.001-08:00

Most application developers tend to over engineer the application design by having objects for almost anything. This adds to the complexity and makes it really difficult to manage. Take this case for example, you need to create a web service which will be accessed by clients over http. You are supposed to implement the token based security for accessing this web service. In a token based security strategy, the client first makes a call to the authenticate method of the web service with a user name and password. The web service will validate the credentials and issue a token with some expiry date and time. The clients will then pass this token in the http header every time they make a call the web service.

The best place to verify this token is somewhere before the web service operation is called instead of verifying it inside all the operations as this is going to be common for all operations in that web service. We now have two places where tokens are used, one inside the authenticate method and the other where we verify the tokens. We can create a token manager class which will be responsible for issuing and verifying the tokens. This class can then be used. This is a good design where the responsibility of token manager is inside one common class.

There is however one more option, we create an interface called ITokenManager instead of a class. We then inject an implementation at run-time. This gives us a flexibility to switch the implementation at run-time if we ever wish to change the way the tokens are issued and verified (e.g. you can switch from XML file to SQL Database). This is a good approach to a flexible design but we are at this point introducing complexity. What if we issue tokens not based on user name and password but something else. In which case we will have to change the interface definition and all hell breaks loose.

Now I am talking about application development and not any framework development, in which case this would have been a better design and not an OO overkill. In an application design it is always experienced that it is better to follow the YAGNI or the DRY principal so that we are always on track and focus on the current problem at hand rather than designing for some future possibilities which may not come or will come in a form which is altogether different than the current.

Switched to google blogger

2011-12-18T21:56:00.000-08:00

Finally I have shifted my blog from Wordpress to Google Blogger :)

The new blogger interface is very refreshing and also very user friendly.

Removing time from an sql datetime value

2011-01-08T09:57:00.000-08:00

The following trick can be used to remove (set it to zero) time from an sql datetime value.


SELECT CAST(FLOOR(CAST(GETDATE() AS FLOAT)) AS DATETIME)

Multiple Inheritance and Interfaces

2010-10-27T22:25:00.000-07:00

When we say we inherit from a class, what is it that we actually inherit?

We inherit the state and behavior of the class. Properties and variables define the state of a class and methods define the behavior.

But when we talk about interfaces, do they have state and behavior?

They don't, as you can only define signatures in an interfaces. Any class implementing this interface must provide the behavior and can have dependent state.

It is very obvious that we implement an interface and not inherit from it.

Many modern languages have learned from the older languages and choose not to support multiple inheritance because of the problems that they have. C# for that instance does not provide multiple inheritance.

There is a misconception that interfaces can be used to implement multiple inheritance in C#. But this is not true, as they do not have anything (state or behavior) that can be inherited.

Solid State Drives (SSD) Now Available in India

2010-09-04T09:27:00.000-07:00

A couple of months back I was looking at upgrading my computer. Specifically I wanted to upgrade my disk space. While searching on the internet I stumbled upon a new technology (it is kinda old as we all use it currently) Solid State Drives. It is similar to the flash memory drives (pen drives) that we use, except that these are available in higher capacities (160GB, 190GB and so on). The advantage of this technology is

It has no moving parts, hence no wear and tear (long lasting)

Since it has no moving parts the seek time is almost zero. So the SDD will take very little time while saving and retrieving data (high performance).

The only disadvantage is that it is very expensive and is not available in very high capacities. On the brighter side, since it is already launched in India we can expect the prices to go down as the market for SSD opens up. Till that time I am planning to buy an internal 1TB SATA HDD ;).

UserControl as a DLL made easy

2010-08-25T22:43:00.000-07:00

To create controls in asp.net there are two options available.

Custom Controls
User Controls

User controls cannot be compiled into a dll and redistributed while a custom control can be compiled into a dll. But a custom control does not have separate files to hold your markup and code which user controls have.

If I can have separate files for markup and code in custom controls, its the best option for creating redistributable custom controls. This will make my design clean as I will achieve a clear separation of concern between my presentation (markup) and behavior (code).

Currently this option is not available in asp.net but there is a nice article to achieve this. The code is also clean and does not pass as a hack but a proper way to create custom controls.

HTML Encode Text in JavaScript

2010-06-30T02:49:00.000-07:00

There are many ways of HTML encoding text in JavaScript. You may use string replacement using RegEx or simply hardcode replacements. These approaches help solve the purpose but make the code bloated and difficult to maintain. There is one clean way of achieving this.


function HTMLEncode(value){
     var div = document.createElement(“DIV”);
     var textNode = document.createTextNode(value);
     div.appendChild(textNode);
     return div.innerHTML;
}

The above code will html encode your text in a cleaner and faster way

Wrap long lines using CSS and JavaScript

2010-06-30T02:02:00.000-07:00

I had this annoying problem of long unwrap-able lines breaking my website layout. After experimenting many fixes I finally settled on the following fix.


<script type="text/javascript">
     $(function(){
          $(".wrap").each(function(){
               $(this).html(
                    $(this)
                         .text()
                         .replace(/([^\s-]{5})/g, "$&&shy;")
                    );
          });
     });
</script>

The above code uses jQuery and Regular Expression to wrap text in tags which have the class "wrap" by adding  after every 5 characters in a long word. For more information on  refer the references section below.

References:

http://www.cs.tut.fi/~jkorpela/shy.html

http://www.quirksmode.org/oddsandends/wbr.html