Most systems today need to handle the user authentication. That means, the password entered during user registration must be stored in the system for later comparison.

It is obvious that the passwords must not be stored in plain-text form. In that case, if an attacker succeeded in getting access to the database, where these passwords are stored (e.g. using SQL Injection), he would obtain the whole list of user names with their corresponding passwords. Then it is very simple for him to impersonate a valid user.

Hashing

However, to check, if the password entered by the user is correct, we do not need the original password. It is enough to have a suitable information, which uniquely identifies it and can be easily computed from each password entering the system.

Such information is the password hash. Hash algorithm is a one-way function, generating a fixed-length string from the inputs (in this case from the given password) with no possibility to derive these inputs back from the computed string. Another property of a cryptographic hash function is that change of one input bit leads to change of many bits in the resulting hash. When the hash function is collision-free, we can assume that the identical hashes imply the identical inputs, from which these hashes are computed.

So instead of the password itself, only its hash will be stored in the system. Every time a user tries to login to the system, hash of the password entered is computed and compared to the stored one.

Slow hashing

However, cryptographic hash functions such as MD5 or SHA are not appropriate. The purpose of these functions is calculation of digest of large amount of data to ensure its integrity. This digest needs to be computed in as short time as possible, and thus these hash functions are designed to be fast. This property is, however, not desirable for password hashing.

As an example take the MD5 function. One 2.13GHz core is able to compute cca 6 million MD5 hashes per second using Cain & Abel tool. Trying every single possible 8 character long lowercase alphanumeric password then takes approximately 130 hours. And that is only one core. Modern computers use more of them, for example with six such cores a password can be cracked in less than a day. Furthermore, we can definitely assume that an attacker has much better equipment.

In order to prevent an attacker from trying millions of hashes per second, we need to use a slow cryptographic hash function for password hashing. Several hash functions were specifically designed for this purpose. These functions include: PBKDF2, bcrypt, scrypt.

Work factor parameters

These hash functions are not only slow, they also come up with work factor parameters defining how expensive the hash computation will be. Although the scrypt function is the youngest one (designed in 2009), it has an advantage over the older ones – it not only defines the CPU cost, but also the memory requirements. That is why scrypt is recommended function for password storage and this article talks mainly about it.

Scrypt uses following work factor parameters:

  • N – number of iterations, related to both memory and CPU cost
  • r – size of the RAM block needed, related to memory cost
  • p – parallelization, defines maximum number of threads, related to CPU cost

These parameters allow to set the memory needed and time it takes to compute one hash. The approximate memory usage for a single hash generation can be computed from the parameters using the following formula:

memory  =  N  ·  2  ·  r  ·  64

The time, on the other hand, is platform-dependent. The graph below shows dependency of time needed for single hash computation on the work factor parameters N and r. The parallelization parameter is set to 1 in all cases. The values in the graph were measured using CryptSharp, the C# implementation of scrypt function, on Windows Server 2012 with four 2.2GHz cores.

csharp_Server12_scrypt

It is needed to specify the computation time as a compromise between the usability and security provided. For example, if we have a system with only one login at a time and high security is needed, we set the parameters to make computation take cca one second. However, in case of many parallel logins this time needs to be set to only few milliseconds.

We can take the above example of password hash cracking. Using scrypt function (CryptSharp implementation) with parameters N=210, r=4 and p=1, hashing of one password takes approximately 10ms, i.e. this 2.2GHz core is able to compute 100 hashes per second. Then computation of all possible 8 character long lowercase alphanumeric passwords takes 895 years.

Attacker goals

Imagine an attacker, who obtained the list of user names and corresponding password hashes. There are now three goals he can have:

  • Crack a password of one specific user (e.g. admin)
  • Crack a password of any user
  • Crack passwords of a longer list of users

Attacks

In the first option the attacker has a password hash and wants to find the corresponding password it was computed from. He can use brute force or dictionary attack, i.e. try many possible inputs to the hashing function and compare the results with the obtained password hash.
An effective method for trying so many hashes is usage of lookup tables. The general idea is to pre-compute hashes of possible passwords and store them in a lookup table data structure (or Rainbow tables for lower memory requirements). Comparison of these pre-computed values with given hash is much faster than hash computation.

The second option is simpler. The only thing needed is to compute hashes of possible inputs and compare each result with all password hashes in the obtained list. Sooner or later the attacker will hit some match.

For cracking a longer list of hashes the attacker does not need to crack one password at a time, he will instead compare each computed hash with all hashes from the list. This way cracking of a hashes list takes approximately the same time as cracking only one specific password.

Salt

The above attacks work because each password is hashed the same way, the same password always results in the same hash. The simplest way of preventing against this is salting. That means, a random string (salt) is generated for each password and used together with it to create a hash.
It is needed to ensure uniqueness of the salts, thus they really need to be randomly generated. Any random number generator can be used, however, cryptographically secure RNGs, such as RNGCryptoServiceProvider in C# or SecureRandom in Java, are recommended.

The salt is a non-secret value, it needs to be stored together with the password hash to ensure its availability to the hash function. Thus, if someone gets access to the hashes, he automatically gets also all the salts. However, the salt power is not in its secrecy, but in randomness.

With different salt, same passwords result in different hashes. Pre-computed hash attack is infeasible due to a large additional memory requirements – an attacker needs to store pre-computed hashes for each possible salt.

Cracking password of any user is reduced to cracking password of a specific one, since the salt for each user password is different.

Also cracking of a larger list of hashes is more complicated with different salt for each password, the attacker has no other choice than cracking one password at a time.

Pepper

In order to increase security even more, we can use another randomly generated string – pepper. In comparison to the salt, pepper needs to be kept secret as it is used as an HMAC key. HMAC is a one-way algorithm based on hash function generating fixed-length string from the input message and a secret key, which in our case is generated pepper.

Since pepper is a secret key, it needs to be generated using a cryptographically secure random number generator, such as RNGCryptoServiceProvider.

public static byte[] GeneratePepper()
{
    byte[] pepper = new byte[32];
    RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
    rng.GetBytes(pepper);
    return pepper;
}

When generated, the pepper must be stored separately in a configuration file with restricted access.

Although an attacker had enough resources to be able to crack the hash function, he would still need this secret value for obtaining the user password. And with pepper randomly generated for each system instance, if one instance is compromised, other remain secure.

Overall scheme

The overall hashing of the password with both salt and pepper looks as follows:

scrypt ( Base64 ( HMAC ( ‘SHA256’, password, pepper ) ), salt, workFactors )

And the C# implementation of this scheme using CryptSharp library:

public byte[] HashPassword(String password, byte[] pepper, byte[] salt)
{
    if (salt == null)
    {
        Console.WriteLine("Password hash not created - salt is null.");
        return null;
    }

    String encodedHmac = HmacBase64(password, pepper);
    return CryptSharp.Utility.SCrypt.ComputeDerivedKey(Encoding.UTF8.
         GetBytes(encodedHmac), salt, n, r, p, null, HASH_LENGTH);
}

private static string HmacBase64(string password, byte[] pepper)
{
    if (pepper == null)
    {
        Console.WriteLine("Password hash not created - pepper is null.");
        return null;
    }
    HMACSHA256 hmac = new HMACSHA256(pepper);
    hmac.Initialize();
    byte[] buffer = Encoding.UTF8.GetBytes(password);
    byte[] rawHmac = hmac.ComputeHash(buffer);
    return System.Convert.ToBase64String(rawHmac);
}

Conclusion

User passwords must never be stored as plain text, always compute its hash using a slow cryptographic hash function. To each password generate random salt and use this value together with the password for hash computation. For higher level of security generate random secret pepper for each system instance.

Of course, security of the user password depends on the password itself. An attacker could still try frequently used passwords such as “123456”, however, with secure storage we can protect him from trying too many of them and from obtaining the strong ones.

Probably every programmer knows switch-case keywords. They are often used to convert data, e.g. some string from another (sub)system to your enum. While working with those, I found two patterns I call best practices.

The first one uses return outright. Its code is short and elegant:

transformGender(String gender) {
    switch(gender) {
        case "M": return Gender.MALE;
        case "F": return Gender.FEMALE;
        case "I": return Gender.INTERSEX;
        default:  return Gender.UNKNOWN;
    }
}

However, some might argue it doesn’t follow the single-exit pattern. If you happen to add e.g. logging, it makes it complicated. Since copy-pasting code would make it a direct opposite of what you were trying to do there, a different pattern should be used. I found one:

transformGender(String gender) {
    final Gender result;
    switch(gender) {
        case "M": result = Gender.MALE;
                  break;
        case "F": result = Gender.FEMALE;
                  break;
        case "I": result = Gender.INTERSEX;
                  break;
        default:  result = Gender.UNKNOWN;
    }
    return result;
}

Obviously, the price for single exit is a longer code (breaks, storing the value). However, it still keeps one advantage of the previous pattern (the basic Java tutorial doesn’t teach it): You can be sure your result is not modified, thanks to final keyword. If you fail to write the value exactly once, a compiler error warns you instantly. Also, it makes it hard to write messy code with preset value and no default branch.

I was curious if the pattern can be used in C#, but it seems it can’t. The keyword final has no equivalent in C#, with readonly not really working in the same manner. Where readonly states that it can only be written in constructor or declaration, final means that the field or variable can only be written once.

Qt Installer Framework is a quite new framework which is currently still in development. The current version contains set of tools and utilities to create installers. The most significant feature is that the framework itself is multiplatform, it supports Windows, Mac OS X and Linux.

Great feature of QT Installer Framework is that it can download the required files from the server. That means it is not required to provide files with the installer. It works with the so called “repositories”. Thanks to this it is also able to update the files without having to download the installer again, because it creates maintenance tool which can update or uninstall the files. However the documentation is not perfect, it is missing a lot of details.

The framework is an open source project. It is built on top of the Qt (it requires static built of Qt).

The framework is really easy to use. For the basic features the user needs to know to work with XML, that is all. For advanced features the knowledge of javascript (QtScript) is required (C++ might be required for the most advanced features).

Usage

Whole installer creation process starts with creating the required folder structure.

Screen Shot 2015-01-28 at 09.16.11

There are two main folders. The config and the packages folder.

Configuration

The config folder contains the installer configuration file (config.xml) and images used in the installer. There are various things that can be configured – Supported Configuration Settings. This is the example what the configuration file could look like:

<?xml version="1.0" encoding="UTF-8"?>
<Installer>
 <Name>YSoft SafeQ Mac Client</Name>
 <Version>4.3.0</Version>
 <Title>YSoft SafeQ Mac Client Installer</Title>
 <Publisher>Y Soft</Publisher>
 <ProductUrl>http://www.ysoft.com</ProductUrl>
 <TargetDir>@HomeDir@/YSoft</TargetDir>
 <AllowSpaceInPath>true</AllowSpaceInPath>
 <InstallerApplicationIcon>ysoft_96</InstallerApplicationIcon>
 <InstallerWindowIcon>ysoft_96_32x32</InstallerWindowIcon>
 <Watermark>modern-wizard.bmp</Watermark>
 <WizardStyle>Aero</WizardStyle>
</Installer>

Packages

The second folder is the package folder. It contains all components that will be installed by the installer. Every component consists of two folders, the data and the meta folder.

The data folder contains all the files that will be installed on the target machine. Installer archives all data to the 7z format and extracts it on installation.

The meta folder contains configuration file(package.xml) for the component and the installation script that will be called when the component is loaded.

This is the example file of component configuration file

<?xml version="1.0" encoding="UTF-8"?>
<Package>
 <DisplayName>CUPS Backend</DisplayName>
 <Description>CUPS Backend</Description>
 <Version>4.3.0</Version>
 <ReleaseDate>2015-01-23</ReleaseDate>
 <Default>true</Default>
 <Script>installscript.js</Script>
 <ForcedInstallation>true</ForcedInstallation>
 <RequiresAdminRights>true</RequiresAdminRights>
</Package>

and here is the full list of possible configuration values – Summary of Package Information File Settings.

The next file is the installation script file (installscript.js). The script is called when the installer is executed and the component is loaded. The script can add new installer wizard pages, prompt user for custom path for the component etc. This is example of a script that extracts component to the /tmp folder and moves it to the Application. Then it adds new item (log out checkbox) to the final page of the installer (the page items or pages have to be designed in Qt designer).

function Component(){
	//Connect signals to functions
	component.loaded.connect(this, componentLoaded);
	installer.finishButtonClicked.connect(this, finishClicked);
}

Component.prototype.createOperationsForArchive = function(archive){
	//Extract and move .app file
	component.addOperation("Extract", archive, "/tmp");
	component.addElevatedOperation("Execute","mv", "/tmp/YSoft\ SafeQ\ Client.app", "/Applications", 
								   "UNDOEXECUTE", "rm", "-rf", "/Applications/YSoft\ SafeQ\ Client.app");
}

componentLoaded = function(){
	//If this is installer load checkbox from .ui file
	if(installer.isInstaller()){
		installer.addWizardPageItem(component, "LogOutCheckBoxForm", QInstaller.InstallationFinished);	
	}
}

finishClicked = function(){
	if(!component.installed)
		return;
	//If the installation was succesful, let the user log out
	if(installer.isInstaller() && installer.status == QInstaller.Success){
		var isLogOutChecked = component.userInterface("LogOutCheckBoxForm").LogOut.checked;
        if (isLogOutChecked) {
			//Todo - logout
		}
	}
}

Here is the documentation for the Component scripting.

The installer is created by executing the Qt Installer tool

binarycreator -c config/config.xml -p packages installer

where -p is path to the packages folder and -c is path to the config.xml file. The last part is the name of the installer. 

This is the look of the final installer on Mac OS X:

Screen Shot 2015-01-28 at 09.48.00

Writing a .NET client for a third-party SOAP web service is relatively simple and straightforward task. Web is full of tutorials or how-to-examples which will help you in case you are new to this field. The first step is generation of proxy .NET class via WSDL.exe utility and its implementation into your project. After that you can simply start using remote resources with all of the cool stuff. Of course, you can always add a WCF service reference (as commonly suggested on many forums), however, sometime this approach cannot be used due to technology limitation or simply you just don’t want to waste your time with setting-up a secured WCF client.

The story behind

Recently we received access to a third-party Java web service offering us some awesome features we wished to implement into our .NET client application. We were provided with a WSDL web service specification and some schema definition files. We simply generated C# proxy classes and started to play with all those new awesome features. After a while we noticed that some of the provided methods are missing in our proxy class. We were sniffing around and found following comment in the proxy class:

// CODEGEN: The operation binding ‘AwesomeMethod’ from namespace ‘http://awesome.namespace/wsdl’ was ignored.  Missing soap:body input binding.

The wsdl utility strangely did not created some of the proxy methods. What happend? Well, all the missing methods actually served for uploading files to the remote server via multipart/related MIME bindings. In WSDL specification it was given as following:
<wsdl:input name="AwesomeMethodInput">
     <mime:multipartRelated>
          <mime:part>
               <soap:body use="literal" part="awesomeMethod"/>
          </mime:part>
          <mime:part>
               <mime:content part="uploadFile" type="application/octet-stream"/>
          </mime:part>
     </mime:multipartRelated>
</wsdl:input> 
Despite MIME attachments are standard part of SOAP specification (see http://www.w3.org/TR/SOAP-attachments), the Microsoft implementation do not support any type of multipart MIME messages (instead he created own standard called DIME, see http://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation). Therefore we had to select different solution.

SOAP web client

The least painful option left for us was to implement the client directly through System.Net library. In fact, writing a web client in C# is not essentially difficult and plenty of examples can be found all over the internet:
var request = (HttpWebRequest)WebRequest.Create(url);
request.ContentType = "text/xml; charset=utf-8";
request.Method = "POST";
request.Timeout = timeout;
request.Credentials = new NetworkCredential("username""password");
using (var stream = request.GetRequestStream())
{
    using (var writer = new StreamWriter(stream))
    {
        writer.Write(postData);
    }
}
Using such example one can easily connect to any http based network resource. Connecting to a SOAP web service is not difficult at all either – in contrast to a simple http web client you have to add only two more things:

 

1) Specify your SOAP action in request header:

request.Headers.Add("SoapAction"@"""awesome.namespace#AwesomeMethod""");

As you can see, the action name consists of method namespace with method name, both delimited by hash. The specification must be wraped in quotation marks otherwise the request will not be performed.

2) Construct a SOAP request according to specification and append it to POST body according to your WSDL specification:

var requestString =  @"<? xml version=""1.0"" encoding=""utf-8"" ?>
<soap:Envelope xmlns:soap=""http://schemas.xmlsoap.org/soap/envelope"">
<soap:Body>
     <message-content/>
</soap:Body>
</soap:Envelope>"
;
Follow your WSDL specification carefully and you will be rewarded with working sample of SOAP client. Of course, you have to parse responses manually in that case, however, it is not such an issue in case you have no other option to call a web service.

How to attach file

If you want to upload a file to a remote SOAP web service, you have to send its content as a part of multipart MIME message. There are many multipart content types which can be used; probably the most common is multipart/form-data used for sending data from web-forms. In our case, the request had to be sent as multipart/related content according to the specification, therefore in the following we will focus on construction of such requests.

First of all, you have to specify appropriate content type and boundary in your request header. The boundary is essential part of every multipart content type, it is any string which delimits single parts of the message and denotes end of the message. The header should be specified as following:

request.ContentType = @"multipart/related; boundary=some_boundary; charset=utf-8; type=text/xml; start=""<first-part>""";

At first you can see specification of our content type followed by definition of boundary (quotation marks must not be used, no white spaces are allowed). Attribute start defines the first part of the message itself through its Content-ID; for multipart/related content type, this attribute must be specified and wrapped in quotation marks. So, if you have the header specified, the message construction with uploaded file is quite simple. You just have to compose following request message and set it as your request body:

--some_boundary
Content-ID: <first-part>
Content-Type: text/xml; charset=utf-8
   
<?xml version='1.0'?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <message-content/>
</soap:Envelope>
--some_boundary
Content-ID: <second-part>
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

...@a!+s1dw32w16qw...your-binary-file…s+61...
--some_boundary--

The specification is quite strict, therefore the request must be constructed exactly as you see it in the example. I mean, boundaries must be prefixed with a double-dash. The footer of whole message must be in suffixed with another double-dash, each header must be on a new line, headers and content itself must be delimited with CRLF constant and so on.

Note that Content-Transfer-Encoding header specifies how the uploaded file will be transferred – for example you can specify binary, base64, utf-8, etc.. This value might depend on specification of your web service. It also determines the way how you will treat content of uploaded file before you attach it to the request body. For example, in case of base64 transfer encoding you have to encode whole file into base64. If you set transfer encoding to binary, you should use BinaryWriter instead of StreamWriter for uploading request body data into your request stream otherwise the uploaded file might be corrupted in your request.

Conclusion

Now you should be able to create your own SOAP requests with multipart/related MIME attachments. We could continue with more and more examples (e.g. with references between message parts), the options are countless. If you want to know more, you can read SOAP attachment specification at http://www.w3.org/TR/SOAP-attachments – there is lot of text, however, if you scroll down you can find plenty of great examples which can suite your problem.