When the head matters

In one of the previous posts I said that the key is the most vulnerable part of the cryptosystem. Today I will concern the topic that is raised from time to time in press, that is understood by everyone and that is nevertheless ignored by everyone. It is the problem of password choosing.

I assume that the reader is a smart person who never writes his passwords down. If you do, you are free not to read the following.

Password is the cryptographic key that is stored in your head. Exactly as in the case with cryptographic key, the attacker will do his best to reduce the number of potential keys he had to try to break the system. Initially he has several good chances to win:

1. The attacker has to try much fewer cases to guess a password than to guess a key. Just compare: to guess a 8 byte key the attacker has to try 2^64 different cases. To guess a 8 character password consisting of alphanumeric characters (letters, numbers and other readable stuff like question marks, ampersands and plus symbols) the number of cases is limited by 2^52.
2. In contrast to keys, passwords usually consist of non-random characters. Many users create passwords basing on their names, or the names of their wives, husbands, children, pets, or other existing words. This fact also narrows the set of potential passwords to try.

Passwords are usually broken using dictionary attacks. Roughly speaking, the dictionary is a list of words that are consequently tried by an attacker. In this case the “word” term is used in sense of “a sequence of alphanumeric characters”, i.e. the dictionary includes not only the natural language words, but also other sequences of characters that potentially can form a password.

In real world everything is worse. Modern dictionaries and password cracking software are much more complex. In our days the dictionaries are generated dynamically basing on the various information know about the owner of the password, such as his or her name, date of birth, friends’ names, favorite drinks and so on. Skilled psychologists are involved in dictionary creation in order to reduce the number of words in it as much as possible and to find out the most likely passwords.

As you see, the attacker has a good chance to guess a password if the latter is not strong enough. That’s why it is important to follow the following rules when choosing a password:

a) The password must contain both letters and digits (and other printable characters, such as brackets, if the environment supports them),

b) The password must be long. Forget about passwords shorter than 10 characters. The 10-character password provides the same protection level as 64-bit symmetric encryption algorithm like DES. But who does use DES today?

c) The password must look absolutely random. It should not be actually random – you may use some rule to produce it (e.g., it may consist of the second letters of the words of your favorite song in college).

d) Invent your own password creation rules. Do not listen to recommendations such as to replace “E” with “3”, “g” with “9”, "l" with "1" and so on. Remember that hackers follow such recommendations too when create dictionaries ;).

It’s a good idea to use a password keeping software. There are several reasons for using it.

First, instead of keeping your passwords in [not fault-free] mind, you keep them in strongly encrypted form and even an iron won’t help an attacker to get it from you ;).

Second, there’s no risk of accidental disclosure of a password – the password is never displayed in readable form and is passed to the applications via the clipboard.

Third, most of such products support strong passwords generation.

There are dozens (if not hundreds) password keeping software products on the market today. Our company used to distribute our own password keeper, KeyLord, but we do not distribute it anymore. Of the existing tools, KeePass keeper is a good choice. Besides other positives, its source code is open, so you can be sure that your passwords are really encrypted with a strong cipher and are not silently sent somewhere via the Internet.

Good luck and keep your passwords well!

Don't hide your keys in the flower pot

“Encryption” word sounds like a spell for many people. “If my data is encrypted, no one can read it”. Thinking that way is a fatal flaw. No one can read it if the key is in safe place.

Many people believe that encryption itself guarantees the complete protection of the data. They say: “the data that is used by our application is encrypted with industry-standard AES algorithm with 256 bit key. Recent research show that in order to decrypt such data a hacker needs to spend a transcendental amount of time, and that’s why our customers should not worry about their secrets”.

It is not completely so.

Modern cryptosystems are designed in the way that the security of the system is delegated to the secret key being used. Although the internals of the underlying cryptographic algorithms are well known, the algorithms guarantee that it is impossible for an eavesdropper to decrypt the encrypted data unless he knows the secret key (to be exact, it is possible for him to decrypt the data, but only by trying all the possible keys one by one; such a big number of keys to try leads to the “transcendental amount of time” referenced by the people from the paragraph above).

So what's the obvious consequence? A hacker will do his best to avoid checking all the keys. In particular, he will try to get the key or some information about the key by other means. That’s why a lack of care about preserving the secrecy of the secret key can lead to a compromise of the entire system. And neither bit of 256 of AES key will help you.

We often face with situations where a secret key is simply hard-coded into the application’s source code. Naturally, such an approach is not suitable. Leaving aside the fact that different data are encrypted with the same key in this case, the key itself is easily accessible to the hacker. He just has to browse the application’s binary code and to extract all the constant values from it. An intermediate hacker will spent no more than five minutes to get the key.

Avoid hard-coding the secret key into the application. If your application needs to encrypt user-specific data, ask user to provide a password and then use this password to generate a strong secret key. To decrypt the data, ask user for a password and use the same procedure to obtain the decryption key. The secret key in this case is nowhere stored in explicit form (except the user’s head), and this fact seriously complicates retrieving it by a hacker.

If due to the certain reasons it is not possible to use password-based secret key generation approach, secret key protection should be implemented in the other ways. In particular, a task of key protection can be delegated to built-in functionality of an operating system. Windows provides several ways for secure storing secret data, such as DPAPI (Data Protection API), LSA, protected registry sections. Use these functions if you need to store a secret key inside an operating system. They have been built by gurus in the field of information security and provide much greater protection than the one you will be able to implement yourself. Besides, they are ready-to-use – and aren’t yours?

Even if OS functionality is not available for you (such cases are rare, but nevertheless possible), never store a secret key in plain form. Instead, generate it on the fly using complex and incomprehensible functions. Of course, this will not stop an inquisitive hacker (he will just use other instruments, such as debugger, in this case), but will prevent the secret key from being disclosed by script kiddies and beginner hackers.

The conclusion. The strongest cryptographic algorithm is useless if you do not care about the proper protection of the secret key. Don't hide your keys in the flower pot.