Question

In one of my current projects, i’m making use of a single-user authentication system. I say “single-user” as i’ve no plans on making this work for multiple users on the same Windows account (simply because it’s not something i’m looking to do).

When the user starts the application, they’re presented with an authentication screen. This authentication screen uses an image (i.e. click 3 specific points in the image), a username (a standard editbox), and an image choice (a dropdown menu allowing them to select which image they wish to use). The image choice, username, and the points clicked on the image must all match what the user specified when setting up the password.

All 3 results are combined into a string, which is then encoded with the Soap.EncdDecd.EncodeString method. This is then hashed using SHA-512. Finally, it’s encrypted using DES. This value is then compared with the value that was created when they setup their password. If it matches, they’re granted access. If not, access is denied. I plan to use the SHA512 value at other points in the application (such as a “master password” for authorising themselves with various different modules within the main application).

In one example, the initial string is 29 characters in length, the SOAP encoded string is around 40 characters, the SHA-512 string is 128 characters, and the DES value is 344 characters. Since i’m not working with massive strings, it’s actually really quick. SOAP was used as very basic obfuscation and not as a security measure.

My concern is that the first parts (plain string and SOAP) could be the weak points. The basic string won’t give them something they can just type and be granted access, but it would give them the “Image click co-ordinates”, along with the username and image choice, which would potentially allow them access to the application. The SOAP string can be easily decoded.

What would be the best way to strengthen up this first part of the authentication to try and avoid the values being ripped straight from memory? Should i even be concerned about a potential exploiter or attacker reading the values in this way?

As an additional question directly related to this same topic;

What would be the best way to store the password hash that the user creates during initial setup?

I’m currently running with a TIniFile.SectionExists method as i’ve not yet got around to coming up with something more elegant. This is one area where my knowledge is lacking. I need to store the password “hash” across sessions (so using a memory stream isn’t an option), but i need to make sure security is good enough that it can’t be outright cracked by any script kiddie.

---

It’s really more about whether i should be concerned, and whether the encoding, hashing, and encryption i’ve done is actually enough. The picture password system i developed is already a great basis for stopping the traditional “I know what your text-based password is so now i’m in your system” attack, but i’m concerned about the more technical attacks that read from memory.

Answer 1

Using SHA-512, it is NOT feasible (at least not before 20 years of computing power, and earth electric energy) to retrieve the initial content from the hash value.

I even think that using DES is not mandatory, and add complexity. Of course, you can use such slow process to make brute force or dictionary-based attacks harder (since it will make each try slower). A more common is not to use DES, but call SHA-512 several times (e.g. 1000 times). In this case, speed can be your enemy: a quick process will be easier to attack.

What you may do is to add a so-called “salt” to the initial values. See this Wikipedia article.

The “salt” can be fixed in the code, or stored within the password.

That is:

Hash := SHA512(Salt+Coordinates+UserName+Password);

Last advices:

• Never store the plain initial text in DB or file;
• Force use of strong passwords (not “hellodave”, which is easy to break thanks to a dictionary);
• The main security weakness is between the chair and the keyboard;
• If you are paranoid, overwrite explicitly (i.e. one char per one char) the pain initial text memory before releasing it (it may still be somewhere in the RAM);
• First learn a little bit about well known techniques: you should better use a “challenge” with a “nonce” to avoid any “replay” or “main in the middle” attacks;
• It is safe to store the password hash in DB or even an INI file, if you take care of having a strong authentication scheme (e.g. with challenge-response), and secure the server access.

For instance, here is how to “clean” your memory (but it may be much more complex than this):

 Content := Salt+Coordinates+UserName+Password;
 for i := 1 to length(Coordinates) do
   Coordinates[i] := ' ';
 for i := 1 to length(UserName) do
   UserName[i] := ' ';
 for i := 1 to length(Password) do
   Password[i] := ' ';
 Hash := SHA512(Content);
 for i := 1 to length(Content) do
   Content[i] := ' ';
 for i := 1 to 1000 do 
   Hash := SHA512(Hash);

When it deals with security, do not try to reinvent the wheel: it is a difficult matter, and you would better rely on mathematically proven (like SHA-512) and experienced techniques (like a salt, a challenge…).

For some sample of authentication scheme, take a look at how we implemented RESTful authentication for our Client-Server framework. It is certainly not perfect, but it tried to implement some best practices.