Long time no written, I know.... I am quite busy these days at work and in my private time working on the web 2.0 startup with my colleagues.

I received an email from Kevin Gao, which is the leading developer of a nice source control software that called SourceAnywhere Hosted of Dynamsoft in order to check out their software tool. I decided to write about this tool, because this one is very suitable to me these days while working on my startup project. I actually needed a good source control in order to manage my code files properly.

So, some conclusions regarding this tool, after working with it close to a month. Let start from the important thing for small developers like me - this tool is FREE to use for up to 3 users, which can be suitable for small to medium projects with low number of developers.

The second thing that was fine by me is the interface of this software, which is very similar to the Microsoft source control (admit it or not - I am a fan of it... ;)), this gave me great a familiar navigation ability between the functionality possibilities and indeed there are some nice possibilities and abilities, like: users and groups roles management and managing your code files (the usual functionality such as rollback, commit, check in/out etc.)

The only disadvantage that I could think about here is a lack of files' state indicator. Dislike other source control tools that I worked with (like: Microsoft source safe control which indicates a file content changes or file state directly in the Visual Studio environment or the SubVersion control system, which indicates the file's state in in the actual file system folder), this tool doesn't indicates it and this is kind of annoying.

Generally I think this is a great tool to use it in order to manage your code version - again for small to  medium applications/projects.

You can read about it and download it free of charge (for up to 3 users of course) here. Have fun!

Hi fellows, how are you?

I read a nice article regarding editing and encrypting/decrypting web.config sections. The nicest thing in that feature is the ability to access to the web.config content via the actual code behind (and) in run-time. (Could be a lot of reasons to access the file from the code itself, and the API is very 'friendly').

Click here to get the directive to this article.

Bye bye...

Hello!

Some intro:
I am starting to migrate a classic asp web application (quite complicated) to .NET 2.0 environment and in the begining (of course) I am starting to learn the functionality of the existing web app.

This morning I came to work and started to rrun the asp web app, but my IIS (5.0) seemed to be dead. I couldn't run anything, even the localhost help page to get some information.

I disabled the "Show friendly HTTP error messages" from the explorer advanced options, and | got this messgae: "The server has encountered an error while loading an application during the processing of your request" - Interesting...

After doing some actions in the IIS, I succeeded solving the problem myself, I just changed the application protection to Low in the virtual directory folder properties.

Some info:
The Application Protection drop-down determines if this IIS Application is to be isolated in its own process, pooled with other apps, or in-process with IIS. This feature comes to give us the ability of isolating applications, configuring them to run in a process (memory space) that is separate from the Web server and other applications. You can configure applications to have one of three levels of application protection: Low, Medium, High.

Another thing is: The application protection determines how memory resources are allocated for ASP pages:

• Low (IIS Process): this level runs ASP pages using the same resources as the web service. The advantage of the low level is that you are given the most permissions and access. The disadvantage is that if the ASP service fails, the web service will be impacted as well.
• Medium (Pooled): this level allocates a pool of memory resources used by all ASP pages. The advantage of the medium level is that you control the amount of resources allocated. In addition, if an ASP page causes the ASP service to fail, it does not affect the web service. The disadvantage is that if one site causes the ASP service to fail, all of the ASP pages will fail.
• High (Isolated): this level allocates a specific amount of memory resources for each ASP application. The advantage to the high level is that if an ASP page causes the ASP service to fail, only that specific site will fail and not the other sites. The disadvantage is that additional resources are used by each individual application pool.

Hope I helped someone...

Hey guys how are you?

After long conversation with my work colleague, I thought that I need to sharpen the evidences about Application Domains - aka AppDomain.

By .NET environment, the concept of an application domain, or AppDomain known as a process. The AppDomain is both a container and a boundary. The .NET runtime uses an AppDomain as a container for code and data, just like the operating system uses a process as a container for code and data. As the operating system uses a process to isolate misbehaving code, the .NET runtime uses an AppDomain to isolate code inside of a secure boundary.

An AppDomain belongs to only a single process, but single process can hold multiple AppDomains. An AppDomain is relatively cheap to create (compared to a process), and has relatively less overhead to maintain than a process. For these reasons, an AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.

Lets take an example from the REAL life:
Assume that you had created 2 ASP.NET aplpications in the same server, what will happen intior the system?

Firstable, the ASP.NET process that runs the web application will run both the applications (you can find the process name in the task manager as aspnet_wp.exe in Windows XP or as w3wp.exe in Windows 2003. Each application will have its own AppDomain including its Cache, Application, and Session objects.
BUT, the code of the same application runs under the same process!

What about static members or shared classes? In this case, each ApDomain will have its own copy of the static members (fields), but of course, the data and code is not shared and will be held safely isolated and inside of a boundary provided by the AppDomain.

Load some new assemblies..
Suppose you want to load an updated dll into the application folder or subdirectory, the ASP.NET runtime will recognize it and and will start a new AppDomain because it cannot insert it to the running AppDomain, the result is that running requests will finish its work and after it they will work against the new AppDomain that holds the new dll and executing code.

Last word...
I think that one of the good adventages of the AppDomain is that you can allocate the wanted memory for your application (under its AppDomain) as much as you want (bounded by the process capability of course) and if there is a runtime crash, the rest of the applciations that runs over the current process will not crash.

I will glad to hear some comments and additions... :)

Hello and good week to all!

These days I am starting to publish here (in my blog ofcourse) a series of articles that discusses with Web Serivces and the most important issue - Security over Web Services (using Microsoft technology ofcourse), because it is quite simple to write a web service that receives/retrieves data and 'do you thing...', but the complexity comes when you want to secure this data that runs over non-secured protocols or web-lines.

This article assumes that you are familier with web services, its porpuse and its implementation and assimilations, if not, you should read some basic tutorials before you start to read this article. (You can fine general example here).

Introduction
WS-SecurityProtocol defines all web services expansion security topics. Its goal is to let you build and use SOAP messages exchange in secured way. This term is quite flexble and it designed in a specific way in order to constitute the base of building a secured Web Service by the different security models like: SSL, Kerberos, PKI.
WS-SecurityProtocol supplies a full support for large number of security tokens, trusted domains, signature formats and encryption technologies.

This component supplies 3 basic mechanisms: Message Confindentiality, Message Integrity, Security Token Propagation. These mechanisms, each one by it own, doesn't supplies perfect security solution, therefore in actual fact, WS-SecurityProtocol builds a block that uses a combination of all there mechanisms and different enhancements to supply a perfect sucurity solution

Main Facts
Before I start explaining and showing the protocol's structure, I want to stand on the basic definitions and terms this protocol is uses:

• Claim - the client's claim (like: name, identity, key, group, rights and more...)
• Security Token - represent a set of tokens.
• Signed Security Token - this is a claimed and encrypted by a specific authority (like: Kerberos ticket or X.509 certificate) security token.
• Proof-of-possession - information that used by a specific "proof process" in purpose to describe the sender data.
• Integrity - a process that comes to note that the sent data hasn't changed while sending the message.
• Confidentiality - a process that comes to ensure that the data is protected and just specific authorized 'players' are allowed to watch it.
• Digest - an encrypted sum of the data sent stream.
• Signature - this is an encrypted communication between the Proof-of-possession and the digest. This action creates a symetric key and public signatures.
• Attachment - this is the physical data that is transfered using the SOAP messages, but is not a part of the SOAP envelop.

We want to ensure that the SOAP message is encrypted properly to avoid dangers, like:

1. The message could be readen and be changed by malicious user.
2. Malicious user can send fake message through the Web Service and by that to get secret information.

Message Security Model

The WS-SecurityProtocol works under the Message Security Model, that comes to prevent such cases like mentioned above. Its behavior is:

The Security Token declares on Claims and Signatures, this mechanism supplies a proof to the knowledge of the sender (in simple words, the data that the sender holds). In addition, the Signature can bind itself with the Claims in the Security Token (in assumption the token is secured).

Claim can be supported (or not) by "secured authority", which is a set of claims, which encrypted or digitally signed by this authority is usually represented by Signed Security Tokens. An example to Signed Security Token set is X.509Certificate - which by this set of claims, the binding is executed between the client identity and the the public key.
Claim that is not supported by any "secured authority", can be secured only when the connection (binding) between the sender and the receiver is secured (secured line, like SSL etc...), for an example, they can agree on a specific message name that is accepted by both of them and by that only they will know that the message is meant for them (because they are both will look forward to get the same name).

Another type of non-secured claim (which is not supported by any "secured authority") called proof-of-possesion. As I descibed earlier, this term confirms that the user has "pieces" of knowledge that diagnosed by the other 'players' which related to it. For an example, lets take a look of username/password security token, the proof-of-possession here, combines another security token in order to confirm the sender's claim. I need to note here, that Digital integrity (see above if you already forgot) for a message can be used as a proof-of-possession, but in theis case it will not considered as a security token.

Message Protection

Another model that comes to prevent such cases as mentioned above (remember...?).
This model claims that all the messages that are being sent, supposed to be encrypted in order to not be negatively affected by hostile factors. The Integrity based message is supplied by leverage of an XML signature with security tokens, in order to notice that the messages has been sent with no data changes of bad influences. This mechanism supports many signatures and players.

A confidentiality (see above for a definition), based message, uses XML encryption with secutity tokens to ensure that the message's parts will be confidential.

In order to supply the the maximum security to the SOAP message, that we'll want to send, there is a need to build the XML file that includes all the filters and headers definitions.
The structure of the XML file includes the <Security> tag, which symbolizes the security definitions. Under this tag it is possible to define all the information about the message security issue.

An XML file cannot hold more that one security tag, this in purpose to allow that each tag (security XML) will taget to other destination. This tag and all its data under, represents the signature steps and the encryption type that the sender used with to send the message.

A typical WS-SecurityProtocol example:

Line 001 and 002, describes the SOAP envelope. Line 003 opens the headers definitions that describes the message. Line 004 to 008, describes the sending message type, the source and destination.

Line 009, open the Security's filters definitions. This label defines the security definitions that the receiver need to be up to (in order to watch the message ofcourse). This header label is closed in line 029.

Lines 010 to 012, describes the security token that message uses, here the usage is username token. (Here the assumption is that the password is well known by the service, and by that, only username is being sent).

Lines 013 to 028 defines the digital signature. By this example, the signature is based on the key that generated from the sender password. Lines 014 to 021, explains the digital signature. Line 015 defines how to normilize the sent information.

Lines 017 to 020, chooses the elements we want to signature. In this example (by line 017), we can see that the body is digitally signed (<s:Body> label, which you can see in line 031).

Line 022, holds tha signature value that derivated from the encrypted information. Lines 023 to 027, holds an information about the security token location, which combined with the signature. In more explicit, lines 024 - 025, defines that this token is located in a specific URL address.

Line 031 to 033 holds the message body.

That it for now. More tutorials at:

• http://www-128.ibm.com/developerworks/webservices/library/ws-secure/
• http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-securitypolicy.pdf

Comments will be appriciated...

Many articles and approaches claims that it doesn't matter what is the application security level, or what is the security level of the environment the application is stored in (like working under SSL using https protocol etc...), you should always save all passwords and secret data encrypted. That because there is always a chance, even little one, that someone could steal your confidential data.

There are many hashing functions and alogorithms, several are MD5, SHA1 and more... but, these algorithms are too old (compare to our modern days), there generates 'only' a 128 bits value, so the space of posible resulting values is 2¹²⁸ in size, which by creating a crack script, like the passcracking project the hash could be broken.

Because of these limitaions and cracking possibilities it is not recommended to use this type of hasing functions. Better solution you wiil see later... (hold on :) ).

One way Hash Functions

The following definitions are taken from the Bruce Schneier's Book: Applied Cryptography Second Edition:

A one-way hash function, H(M), operates on an arbitrary-length pre-image message, M. It returns a fixed-length hash value, h.

h = H(M), where h is of length m

Many functions can take an arbitrary-length input and return an output of fixed length, but one-way hash functions have additional characteristics that make them one-way [1065]:

Given M, it is easy to compute h.

Given h, it is hard to compute M such that H(M)= h.

Given M, it is hard to find another message, M’, such that H(M) = H(M’).

In some applications, one-wayness is insufficient; we need an additional requirement called collision-resistance.

It is hard to find two random messages, M and M’, such that H(M) = H(M’).

Now, by getting the main idea of the basic hashing algorithm by the Bruce Schneier's Book definitions, I want to show you better alternatives that comes to replace and enrich the old ones.

WHIRPOOL generates a 512 bits output, RIPEMD, uses 160, 128 or 320 bits output, but I want to focus in the SHA-2, function that generates 256, 512 bits ouputs, because there is available API in Microsoft.NET framework.

The main classes that implements this cryptografic algorithms are:

• System.Security.Cryptography. SHA256Managed
• System.Security.Cryptography. SHA384Managed

• System.Security.Cryptography.

  SHA512Managed

Now to the implementations. The following code below shows you an example how to use this function in porpuse to encrypt a password or just confidential data that you want to store hashed:

byte[] data, encryptedBytes;
string hashedPassword =string.Empty;

data = Encoding.Default.GetBytes(plainPassword);
System.Security.Cryptography.SHA256 sha2 =new System.Security.Cryptography.SHA256Managed();
encryptedBytes = sha2.TransformFinalBlock(data, 0, data.Length);
foreach (byte b in sha2.Hash)
   hashedPassword += Convert.ToString(b, 16).ToUpper().PadLeft(2, '0');

sha2.Clear();
// hashedPassword holds the hashed string

This example above encript the plain pasword using SHA-2 algorithm.

The following example uses a salt which comes to help reduce the risk of dictionary attacks, the code appends random bytes (so-called "salt") to the original plain text before generating hashes. Please keep in mind that salt can only help against prebuilt dictionaries. If an intruder gets access to your system and uses a brute force attack, salt will not provide much value.

That's it, now use it properly and try to avoid as much as you can from brut attacking...