Security Is... Issue 2

Occasionally, one happens to find themselves in the situations that look quite unpromising... yet, even having been eaten one always have at least two ways to escape ;).

Security Is...

Our company launches a "Security Is..." series of weekly thematic comic strips. The main goal of the series is dethroning a popular fear that information security is something extremely complex, and showing that that "intricate security stuff" is in fact pretty much close to the basic things in our life that we come across every other day. We also hope that our little effort will help people start "thinking securely", that is essential in today's realities.

We would be thankful to everyone for sharing the pictures with your family, friends and co-workers - let's populate the idea of "living securely" together!

Some governments around the world, frightened by the interception of two bombs directed to the United States, decided to introduce stricter security measures for air transportations. To my sincere disappointment, the decisions made illustrate the complete helplessness and lack of "security thinking" of the tops.

In particular, the following additional measures were put in place:

As a precaution Britain said it was banning air passengers from taking large toner cartridges onto planes as hand luggage, while Nigeria said it would improve the scanning of cargo bound for the United States.

Okay, the terrorists will never be able to bring bombs on board inside toner cartridges anymore. They have nothing to do but use laptops, smartphones, pocket radios, Kens and Barbies and electric guitars for this purpose. The terrorists originating from Nigeria will just buy two tickets, from Nigeria to, say, Moldova (to bypass improved cargo scanning), and, further, from Moldova right to the United States.

Germany said it had suspended passenger flights from Yemen, and was considering expanding a cargo flight ban to other unnamed countries.

Wow. If Moldova won't accept flights from Nigeria, I know the country to use instead ;).

Britain said it was also banning all air freight sent from Somalia, adding to a ban on Yemen cargo flights imposed at the weekend.

Just another shot at the sky.

All the above cases share the same problem. There is a number of holes in the fence the attackers can reach the rancho through. Having caught the attackers by the hand getting through one of that holes, the government patches it... but does not consider the other holes, even though they are pretty close to the patched one. Disallowing to bring cartridges on board with a hand luggage, as well as rejecting flights from Yemen and Somalia, will change nothing. There is nothing that stops terrorists from simply using hand stuff of other kind and different countries to reach their goals. This is so obvious that I tend to think that either the governments have nothing to oppose to the terrorists with, or... well, nevermind.

Thanks to cracksinthepavement.com for the picture.

Security versus Usability

I've been watching yet another Air Crash Investigation movie on NG yesterday. The film was dedicated to DC9 crash in Detroit (August 1987). The first thing that impressed me much was that the crash was very similar to MD82 crash in Barajas two years ago (August 2008). In both cases the pilots did not extend flaps and slats for taking off. In both cases an aircraft failed to gain enough lift and crashed in seconds after takeoff.

The second thing I'd like to mention here is a principal one. The system that must have warned the pilots about bad takeoff configuration was turned off. Moreover, it has been turned off far before takeoff, and it has been turned off intentionally. The investigation has shown that the warning system was designed quite badly; it used to fire false "bad takeoff configuration" alarms in irrelevant situations. It was also discovered that it was a "good practice" amongst DC9 pilots to turn that system off just to prevent annoying false alarms. Thus, when the aircraft was accelerating down the runway, there was no advisor to let the pilots know that the aircraft is not ready to take off.

That was obviously a usability issue. The system was too annoying, so most of the pilots decided to turn it off just to save their ears from that zz-zz-zz-zz humming (even though turning it off caused a real risk for their lives).

So what do you want from a user (a skilled one or a dummy -- it doesn't matter) who is forced to scramble through that firewall warnings, antivirus software warnings, SSL certificate verification prompts, phishing or "dangerous site" warnings, ...? All that warnings (and correct answers to them) are vital for the PC to remain secure. However, a user does not want to think about security. All they want is to solve their problems: connect to an office via SSH, check mail at Google, download some new game to play. All that warnings just prevent them from solving their problems effectively; besides (and it is quite important) they will be able to resolve the problems simply by accepting everything asked by the protecting software. "Do you trust this certificate?" - "Sure I do, let me get in faster". "This distribution is not signed by the vendor. Should we run it?" - "WTF, that's a brand new Doom VII, you MUST run it!". And so on.

What I intend to say is that users will react similarly to DC9 pilots until security software stops annoying them. It is silly to ask users myriad of vital security-related questions a day and expect them to answer to each of those questions thoroughly. As a matter of fact, most of home PC security software is more or less perfect. However, a user is the weakest link in the chain and can make castle walls disappear with a single mouse click.

Because of all these, the strategic direction of IT security concepts (and, as a result, security software) is quite clear for me. It's all about usability. The perfect "secure system of the future" does all the security at the background, invisibly to the user. This might seem impossible in today environment (as all the today security depends on the trust relations in the end, and the user is the final instance to define trust), but it is the only way to make the things more or less secure. It is an absolute requirement to exclude the user from being involved into the process of making security-related decisions.

Fundamental vulnerability in PDF

Florian Zumbiehl discovered a fundamental flaw in the PDF standard that makes it possible to create valid digital signatures over an arbitrary content.

The flaw allows an attacker to create a pre-defined document with two different contents (say, one "visible" to the signer and another one "hidden"), make the signer sign the "visible" content, and then substitute it with the "hidden" one without invalidating the signature. I should note that signing should be performed with special software that "knows" about the flaw and the "Janus" feature of the document, and can sign it in the proper way to make content substitution possible in the future.

As far as I am aware of the way the Acrobat works, it cannot be used to perform such an attack on the signer. However, the flaw itself is extremely serious and may lead to various problems in future. For instance, one can attack their own signature and then insist on revoking it, arguing that the signature was attacked by a third party.

Big Red Brother (and his buddy) are Watching You

What would you say about the software that silently installs another piece of software from third-party vendor to your computer, which, in turn, collects information regarding your computer's security features (the presence and version of firewall, anti-virus software etc.) and requires Internet connection (!) to be available?

The software is called Adobe Flash Player extension for Firefox; the silently installed third-party tool is McAfee Security Scan Plus. That's it -- having installed a minor extension to a browser, you get a system-wide trojan curios piece of software installed to your PC.

Leaving aside the moral and legislative aspects of such scheme (and please don't say it's just business -- similar schemes were neglected even by Russian gangsters in 1990ths), just wish to warn you to be careful with these. Nobody knows what exactly information collects and sends out the installed tool, neither what is the purpose of collecting such information.

SecureBlackbox the eighth

SecureBlackbox 8.0 is out. We are happy to introduce a number of exciting new features, including Silverlight 3 and 4 support, secure Cloud components (Amazon S3 and Windows Azure data storages are initially supported) and secure DNS capabilities. I wish everyone to have a good experience with the product!

Autoinfect

The invention of autorun (and, similarly, autoplay) feature, in the form it exists today, is one of the biggest platform developers' mistake. A feature with doubtful impact, it has become an easy mechanism for malicious software to reproduce itself. Desktops in Internet cafes and copy centers proved to be excellent friendly hubs where viruses and trojans use to spawn.

What is quite beyond my understanding is that at the same time the very most of the flash drives released today do not promote a write protection switch! This forces me to use my good old 128Mb Chinese noname in public places (such as e-cafes or hotels), as neither of my newer ones provides write resisting capabilities.

As raw criticism is not that constructive, I will explain my own point of view on how autorun should have been implemented correctly (if it should have been):
- Never, NEVER runs without prior OS notification (stating the name of the file, the vendor etc.). If invoked under administrator account, OS displays another dialog proposing to run it under guest account.
- No binaries (neither unmanaged nor managed), no scripts. DHTML (runs in default browser), maybe Silverlight or Flash. "Web" security policy.
- Turned off by default.

It is necessary to understand that autorun is the easiest way to run unknown code on the machine. By simply inserting the untrusted (not yours or write-unprotected) flash card or CD into the drive you can stuff your PC with a swarm of parasites. No further actions are needed. Just keep in mind that someone might silently plug his malicious tiny flash into your notebook's USB when you are drinking your martini at the airport. So the best choice in today environment would consist of three basic rules:

I. Turn autorun off and forget about it.

II. Use a USB flash card with write protection switch and disable writing wherever possible. It would be ideal to only enable writing when inserting the card into your computer.

III. Wherever possible, use "passive" approach to file distribution. Ask your friend to copy down the files you need from his computer to his flash disk; disallow writing on that disk before inserting it to your computer. The same rule applies to the reverse process: copy down the files your friend needs to your flash disk and disallow writing before inserting it to your friend's computer. Such approach will help protect your computer from infecting with the viruses living in your friend's computer, and your friend's one with the viruses living in yours.

Following these three simple rules above will decrease the speed of epidemic spread and make your computer (and the computers of your mates) healthier.

The future of IT security

The situation in the field of informational security is very far from the perfection today. The main problem is that it's just too complex, while a lots of people, mostly unprofessional, are forced to deal with it. Not understanding the potential effects and risks completely, they often prefer to ignore non-important or too sophisticated details (from their point of view), rather than to set up the things as they need to be.

As an example, let's recall the security subsystem available in Windows 2000. The OS itself provided a powerful mechanism for access rights management, multi-user features, flexible PKI support etc. However, most of the users of this system preferred to work with Administrator privileges, negating most of the security features provided by the system and making the core of the system open for external intrusions. What's the reason? The proper configuration of security subsystem involved non-trivial manipulations from a user. It was much easier for him to add himself to the administrators group and throw all the problems away. I am glad to see the progress made in this field by Microsoft in subsequent versions of their OS.

That's why it is obvious for me that the main trend in IT security for the middle-term future is directed to simplification of the interfaces of security subsystems. The unrelated people do not have to deal with e.g. certificate management, web site authenticity confirmation (does anybody read the text displayed on that strange popup in the browser?), or choosing between explicit and implicit TLS modes when connecting to their favorite FTP archives. Transparency of the security subsystems is the main goal for the future. The people only need to be confident that the data they store in their PC's are safe, just as they are confident about the safety of their money on a bank account.

On unfair methods in IT security

Vladimir Katalov, the CEO of Elcomsoft (a company who mainly specializes on password recovery solutions), has written a note about their participation at InfoSecurity event. I have no intention of re-posting or quoting his message here, so that you had a chance of enjoying the origin.

I have nothing to add to his words as well, except that the inconsistence of "security through obscurity" postulate has been recognized quite long time ago.

SBB 7.0 is here

SecureBlackbox 7 is out now - enjoy new exclusive features and improved performance!

SBB 7 introduces extended cryptographic token support, FIPS 140-2 compliance mode and support for elliptic curve algorithms (ECDSA and GOST).

Support for GSS-API interface in SSH components and creation of self-extracting OpenPGP executables is expected in SBB 7.1.

Public Key Cryptography for Boy Scouts

Let’s imagine that someone (let’s call her Sophie – actually, we can use any desired name, but I would be pleased to use a name of my favorite actress – hope, she would be too :)) is willing to send you something quite sensitive – let it be an old map of the treasure island where captain Flint has hidden his chest full of golden coins. As a true woman, Sophie wishes to ask you – her brave knight – to sail to that island, fight the dragon and bring the treasure to her (I am not sure if there actually was a dragon, but the girls do like that sort of things, so we imagine that the monster is there :)).

However, there’s one problem: a river stands between you and Sophie. The only way for her to send you a map is to use the services of a boat driven by an old one-legged guy with a parrot on his shoulder, and this guy appears not to be that honest. The boat is quite small for two, so neither she nor you can accompany the map in its transfer across the river.

As you are a smart guy, a real knight, you quickly find a solution. Sophie should take a box with a lock, put a map there, close the lock and send the box to you via the boat. Once the box is here, you’ll open the lock and get the map. A great idea, isn’t it? Well, let’s try. Sophie finds the appropriate box, locks it with a key and calls the boat. But… wait a minute. You need the key to open the lock. But the key is on Sophie’s side, and obviously she cannot use the boat to transfer it to you.

You are sitting on the shore and thinking. You understand that Sophie should be able to close the lock and you should be able to open it, but the key should never be transferred across the river. And suddenly you get it! The solution is really simple. You will take a box with a self-closing lock, similar to the one shown on the picture at the left, and send the box to Sophie with an open lock, leaving the key in your pocket. Once Sophie receives the box, she puts the map there and pushes down the shackle. Now she can freely send the box with that strange guy, as she knows that he can’t open the lock without having a key.

An attentive reader may propose the following solution: let Sophie lock the box with a key and send the box with a boat. When the box arrives to the other side, let she call the boat once again and ask the guy to transfer the key. Well, yes, this solution will work (actually, it even suits one of the core principles of cryptography – never store a key along with encrypted data). However, you will not be able to use the same box or lock again, and who knows how many old maps Sophie is going to find? Besides, this solution is not applicable in the digital world, where an old one-legged guy can always do a copy of whatever he transfers and unlock the box once he gets the key.

The above story describes a method that cryptographers call public key (or asymmetric) encryption. In every public key cryptosystem a key consists of two halves called public key and private key. Public key is publicly available, while a private one should be kept in a safe place by its owner. Everyone can encrypt data with a public key, but only the one who possesses the private key will be able to decrypt it. In our case, the open lock is a public key, and the key in the pocket is a private key.

Let’s consider another situation. You and Sophie wish to send letters to each other across the river, and, as you are really a romantic couple, the number of letters is expected to be quite big. Of course, you can use the above scheme with a box with a self-closing lock. However, there will appear two disadvantages of such a scheme applied to our romantic task. First, you will need two boxes (a first one to transfer letters from Sophie to you and a second one – from you to Sophie). Second, a boat will have to do twice more trips across the river than the actual number of letters transferred (there is an extra “dummy” transfer of an empty open box for each letter). This is not critical if the transfers are free of charge, but I am pretty sure that the guy’s parrot eats plenty of corn and that’s why the transfers are performed on a paid basis.

Now that you are not a greenhorn in public key encryption, a reasonable idea comes to your mind quite fast. You will take a box with a lock that can be both opened and closed with the same key (see the picture at the left), and two identical keys that fit it. Then you will ask Sophie to send you an empty box with an open self-closing lock, exactly the same as you used to transfer the map. Once the box is here, you will put one of the two keys inside, close the lock and send it back to your girlfriend. She will open the box using her key and get the key that you’ve put inside. Now – voila - you have a box with a lock and two keys that fit that lock, one on your side and another on Sophie’s side, and you can start exchanging the letters using this box. A box with a self-closing lock is not needed anymore, so Sophie can put it aside.

The second case is a classic key exchange example. A general key exchange method allows two (or more) parties to set up a shared key by communicating over insecure data channel. A lot of key exchange methods are based on public key cryptosystems. The above case is based on public key encryption scheme; however, underlying encryption algorithm is not a requirement though. In modern cryptography key exchange algorithms serve a very important task of sharing a symmetric cipher key between peers using extraordinary strength provided by the asymmetric algorithms.

To be continued...

Secure File Transfer Protocols

There are two widely used secure file transfer protocols that are confused quite often. The talk is about SFTP and FTPS. Although the purposes (and the names ;)) of the protocols are quite similar, they are rather different and, what is important, incompatible with each other. I will concern the main differences between the protocols in this article.

SFTP (SSH file transfer protocol) runs as a subsystem on top of secure SSH channel. All the traffic is always encrypted, the security is guaranteed by the underlying SSH protocol.

FTPS (FTP over SSL/TLS) is an improved version of classic FTP protocol, where TCP connection is optionally secured with SSL. In all other aspects the protocol is compatible with good old FTP.

What is interesting is that neither "SFTP" nor "FTPS" is an official name of the corresponding protocol. There’s even no “complete” standard for SFTP – all the versions of this protocol are only available as internet-drafts. FTP over SSL is particularly defined in RFC 2228, however, most of existing implementations offer much more features than are defined in that RFC (for instance, “implicit FTP” term was invented by the developers of one of the FTPS products, such a term has been never officially defined). Thus, both protocols are actually standards de facto, but not de jure. This fact causes a lot of (in)compatibility problems between different software implementations.

Let’s shortly consider the differences and the features common for both protocols.

1. Transport

SFTP runs over secure SSH channel. Moreover, one can establish several parallel SFTP connections through a single SSH (and TCP) connection. Moreover, one can additionally run a remote shell through the same SSH channel. Security of FTPS is optionally guaranteed by SSL/TLS protocol. Each FTPS connection requires a separate TCP connection to be established to the same server. Besides, transfer of a file requires a separate TCP connection, called data connection. FTPS works in either active (client opens a listening data port and server connects to it) or passive (vice versa) mode.

2. Security features.

Obviously, security features of the both file transfer protocols rely on security features of the underlying security protocols. Both SSH and SSL provide the following security features: server authentication (mandatory in both protocols), client authentication (optional in SSL, mandatory in SSH), strong key exchange, data encryption and integrity protection. Strengths of the algorithms used in both protocols are approximately the same. However, unlike SSL, which allows only certificate-based peer authentication, SSH provides support for a number of possible client authentication methods, such as password-based, keyboard-interactive and public key-based.

3. File transfer features.

In general, SFTP is more flexible than FTPS. In particular, SFTP provides access to remote files as if they were local (via Open/Read/Write/Close functions), emulating free access to them. Besides, SFTP declares a standardized way for file attributes requests. It is known that FTP does not provide a unified way to request a file list; the developers of FTP clients are forced to implement reading of dozens of different file list formats to make their implementations compatible with as many existing servers as possible. Actually, there’s a reason for it – FTP originally has been designed as human-readable protocol, not machine-readable.

4. Firewall friendliness.

FTP is known to be not a firewall-friendly protocol. This is caused by the necessity of establishing a second connection for data transfer. This fact resulted in invention of different secure/insecure mode switches (such as PROT and CCC commands) and other crutches. As SFTP does not require secondary connections, it does not have problems with proxies and firewalls.

5. Extensibility.

Both protocols can be extended with new commands.

As you see, there are much more reasons for using SFTP rather than FTPS. There are only two features that may put SFTP behind FTPS:
* SSL provides standardized support for X.509 certificate authentication. SSH does not support X.509 certificates natively, making PKI infrastructure hardly used with SFTP.
* FTPS provides independent encryption modes for control and data channels, what might be suitable for logging and monitoring purposes.

If you are interested in more details about the differences between SFTP and FTPS, please see the following article.

Besides FTPS and SFTP, there do exist other, more complex, transfer protocols, such as OFTP. However, due to low popularity and specifics of use of such protocols, comparing them to mainstream FTPS and SFTP protocols is not correct enough. I will concern OFTP and its main features in one of the future posts.

Another stimulus to write secure applications (taken from the Washington Post):

A data breach last year at Princeton, N.J., payment processor Heartland Payment Systems may have compromised tens of millions of credit and debit card transactions, the company said today.

If accurate, such figures may make the Heartland incident one of the largest data breaches ever reported.

It is not clear at the moment what exactly has caused the breach. The paper talks about some malicious piece of software, however, it says nothing about how had this code got to the payment processing network. In any case, a lack of attention or qualification (hope, the former) of developers and security officers has resulted in serious damage for the Heartland Payment Systems' reputation.

The data stolen includes the digital information encoded onto the magnetic stripe built into the backs of credit and debit cards. Armed with this data, thieves can fashion counterfeit credit cards by imprinting the same stolen information onto fabricated cards.

On the significance of authentication

As I said in the very first post, many developers think that it is very easy to make their software applications secure. One should take a software component that implements the necessary security protocol, plug it to the application and have the application robust, reliable and secure. Though such straightforward approach may work for simple applications, it is very dangerous to use it for securing complex systems. Why dangerous? Because it only gives the illusion of security. You think that your system is secure, while it actually isn’t.

Let’s consider TLS. What can you say about it? TLS is a transport-layer protocol that secures TCP data by encrypting it with robust industry-standard algorithms. A malicious person who intercepts network traffic sees just a sequence of meaningless characters and not the original message.

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

Besides encryption, TLS offers a pack of other security services that are often ignored. One of them is server authentication.

Basically, to authenticate someone is to ensure that this someone is the person he pretends to be. When I was ten, I authenticated my friend Michael by three consecutive knocks on the door. The bank guard authenticates the officer by comparing his face to the photo on his PhotoID. Your computer authenticates you by prompting you to provide your account name and password.

In TLS, authentication is performed with the use of digital certificates. Each TLS-capable server has an associated certificate which contains information about its owner, such as host name (or IP address), organization name and its geographic location. Certificates are issued by a trusted insitutions called certification authorities (CA). Three widely used certification authorities are Thawte, Verisign and Comodo.

CA is not required to be a worldwide organization with thousands of employees. To be exact, any person who has a computer can become a CA and issue certificates. However, who will trust them? If my friend Michael told about three secret knocks to everyone, would I consider the knocker to be trusted?

How the authentication is performed? Besides the certificate, the server possesses a corresponding entity called a private key (which can be imagined like a very long binary sequence). Certificate and private key are complementary entities that can be used to perform complementary cryptographic operations. Private key can be used for signing data, while the corresponding certificate can be used for validating the correctness of such signatures. Certificate can be used for data encryption, while only the corresponding private key is able to decrypt data encrypted with such a certificate.

It is obvious that unlike the certificate that is publicly available, the private key must be kept in secret by its possessor.

To authenticate himself to the client, the server uses his private key to sign an arbitrary chunk of data provided by the client. The client then uses server’s certificate to validate the correctness of the signature. As nobody else knows is supposed to know the private key of the server, correctness of the signature ensures that you are talking either to a real server or to someone who has stolen his private key. I do not consider the latter here, this case will be discussed in future posts.

TLS also provides support for client authentication. It works exactly in the same way with the only difference that the client signs the data and the server verifies the correctness of his signature using client’s certificate.

The problem with TLS is that a lot of people who use it think that encryption is its primary feature, while authentication is a secondary one. It is absolutely not correct! There’s no sense in locking the safe if the guard opens it for everyone who asks him about it. If your application does not care about server authentication, it is vulnerable to a dozen of different attacks. One of the most common and easy-to-use attacks based on the lack of authentication is server substitution. Someone just creates a fake server in the network that identifies himself as the original server (there’s a million ways to do this, I omit the exact how-to. Just keep in mind that it is much easier than it might appear at first glance). As no authentication is performed, you will never understand that you are talking to the wrong server. What is worse, the illusion of security is preserved. You are using TLS, so you are secure, aren’t you?

The security of the overall system is defined by the security of its weakest component. There’s no sense in locking the door if the window is open.

Why authentication is often ignored by the developers? I think there are three general reasons for this.

First, authentication is not something one can touch. Encryption is an obvious thing. Authentication is not as transparent as encryption. Besides, 8 persons of 10 consider that “security” is equal to “encryption”.

Second, implementing correct authentication procedure is not an easy task. Some developers (and PM’s/CTO’s as well) consider this task too expensive and do not want to spend a lot of time in implementing it correctly. “Everything works fine without it, so why do we have to postpone the release date of our product for two months for the sake of the feature that no one will have a chance to see?”. Was it a long time ago you’ve heard about 10000 credit card number hijacking the last time? It is likely that their system “worked fine” too.

The third one, the lightmost reason, is the [absolutely reasonable] wish of developer to make the software as much user-friendly as possible. Authentication often requires interaction to the user. Sometimes it is necessary to ask user if he trusts the particular web site or application, sometimes another warning should be displayed. Some developers think that this will bother user. Will not the user be bothered by the stolen password database?

Authentication of the remote is absolutely necessary. The most impenetrable door will provide no help if everyone has a key to unlock it. The most progressive encryption algorithm is worth nothing if you are exchanging encrypted data with a wrong person.

Offtopic: Merry Christmas and Happy New Year. Have a nice '09!

A very good article has been published by CWE. Top 25 Most Dangerous Programming Errors must be read by any software developer who seeks to develop secure and, what is more, safe applications.

The article divides all the programming errors in three classes, (a) insecure interaction between components, (b) risky resource management and (c) porous defences. Top 25 includes both good old errors (such as buffer overrun), web-specific XSS and SQL injection errors, and issues caused by the lack of attention to application's security.

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.