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!

The Buzzwords

How often do you hear statements like “The traffic between the client and the database server is protected with TLS protocol, so I absolutely do not worry about the privacy of the data being transferred.”? Or, “Our password manager uses AES algorithm to encrypt password database – no one has succeeded in breaking AES yet”. TLS, SSL, SSH, PKI, AES, MAC, 3DES… It is believed that if a system utilizes some popular security technology named in good-looking and incomprehensible way, such system must be unbreakable by default.

In his “Nineteen Eighty-Four” novel, George Orwell aptly described this problem by the example of Newspeak language. Shortenings and abbreviations make us lose the real meaning of terms. Psychologists say that it is common for people to trust abbreviations more than the equivalent “expanded” phrases.

In the process of development of a system it is absolutely necessary to clearly understand the features provided by the chosen security technology. Good-looking name or just a buzz in press must not have an influence on your choice. The developer needs to know all about the technology – the way it works, the provided protection level, requirements for the operational environment, and especially the shortcomings of the technology. The lack of such knowledge can easily destroy the gains of the use of the technology down to the zero.

In future posts I will concern popular information protection technologies and try to reveal the hidden meanings of opaque buzzwords.

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.

The general principle of information security

Implementation of any security-related function in any project should be done according to the following principle: the system is secure if the cost of hacking it is greater than the benefits of the result of the hacking.

The amendment. And the cost of implementing such function for the developer is cheaper than the worst consequences of the disclosure of secured information.

There’s no sense in building a multi-level data protection system if the data being protected is a high scores file of a computer game (unless it’s good old Digger game, of course ;) ). It is unwise to use 56 bit DES keys to protect the personal data of bank customers.

Any protection should be adequate to the data it protects.

Intro

Good evening,

My name is Innokentiy Ivanov, I am the manager of EldoS SecureBlackbox product – a comprehensive library of security-related software components. For six years we helped thousands of our customers all over the world to successfully integrate security features into their software products.

Unfortunately, in our work we faced with quite an unpleasant fact. It turned out that the heads of many companies and separate software projects have a kind of superficial understanding of data protection and information security problems. In particular, they suppose that adding third-party security components is enough to make their product secure. They delegate the task of implementing security features to the ordinary programmers, in the belief that this task is no more complex than any other basic subtask of the project. They are wrong. Integrating security features to a project requires a good understanding of this task and certain level of skills in information security field. The developer responsible for adding security to the project should clearly understand what exactly security problems he has to solve, and which ways of solving them are the optimal ones. If the person responsible for security in your project does not have such skills, you have a chance to get the illusion of security.

The purpose of this blog is the consideration of the most typical mistakes and misconceptions related to integration of security features to software products. I hope it will be useful to the managers of the products containing security modules, as well as to the developers responsible for implementing those modules in robust and safe way.

So, let's start building safe and secure world.