OWASP Guide to Building Secure Web Applications and Web Services, Chapter 19: Cryptography

News Analysis



This article is provided by special arrangement with the Open Web Application Security Project (OWASP). This article is covered by the Creative Commons Share-Alike Attribution 2.5 license. You can find the latest version of this article and more free and open application security tools and documentation at http://www.owasp.org.



Platforms Affected

Relevant COBIT Topics
DS5.18 – Cryptographic key management

Initially the realm of academia, cryptography has become ubiquitous thanks to the Internet. Common every day uses of cryptography include mobile phones, passwords, SSL, smart cards, and DVDs. Cryptography has permeated through everyday life, and is heavily used by many web applications.


The proper and accurate implementation of cryptography is extremely critical to its efficacy. A small mistake in configuration or coding will result in removing most of the protection and rending the crypto implementation useless.

A good understanding of crypto is required to be able to discern between solid products and snake oil. The inherent complexity of crypto makes it easy to fall for fantastic claims from vendors about their product. Typically, these are "a breakthrough in cryptography" or "unbreakable" or provide "military grade" security. If a vendor says "trust us, we have had experts look at this," chances are they weren't experts!

Cryptographic Functions



The identity is not of the user, but of the cryptographic key of the user. Having an insecure key lowers the trust we can place on the identity.

The concept of non-repudiation is particularly important for financial or e-commerce solutions. Often, cryptographic tools are required to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions.

For example, a customer may request a transfer of monies from her account to be paid to another account. Later, she claims never to have made the request and demands the money be refunded to the account. If we have non-repudiation through cryptography, we can prove – usually through digitally signing the transaction request with their private key, that the user authorized the transaction.

More commonly, the biggest concern will be to keep information private. Cryptographic systems primarily function in this regard. Whether it be passwords during a log on process, or storing confidential medical records on a database, encryption can assure that only users who have access to the decryption key will get access to the data.


Cryptographic Algorithms

Asymmetric (also Public/Private Key Cryptography)
Asymmetric algorithms use two keys, one to encrypt the data, and either key to decrypt. These inter-dependent keys are generated together. One is labeled the Public key and is distributed freely. The private key must be kept secure.

Commonly referred to as Public/Private Key Cryptography, these algorithms can provide a number of different functions depending on how they are used. The most common implementation of public key cryptography is certificates. The public and private keys are encoded using one of several standardized formats that enable relatively simple transport and key management.

If we encrypt data with a user's public key (which is publicly available), we can send the data over an insecure network knowing that only the associated private key will be able to decrypt the data. We have ensured that the message is confidential.

Alternatively, if we encrypt data with our private key, only our public key can decrypt – we have just proven the message's authenticity, since only our key could have generated the message.

A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their 'root' certificates, which in turn authenticate the public certificate presented by the server.

PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using the RSA or other algorithms.

Symmetric keys share a common secret (password, pass phrase, or key). Data is encrypted and decrypted using the same key. These algorithms are very fast, but we cannot use them unless we have already exchanged keys. Common examples of symmetric algorithms are DES, 3DES and AES. DES should no longer be used.

Hash functions take some data (and possibly a key or password) and generate a unique hash or checksum. Since this is a one-way function, it is normally used to provide tamper detection.

MD5 and SHA-1 are common hashing algorithms used today. These algorithms are considered weak (see below) and are likely to be replaced after a process similar to the AES selection. New implementations should consider using SHA-256 instead of these weaker algorithms.

Key Exchange Algorithms

Stream Ciphers
Stream ciphers, such as RC4, are vulnerable due to a property of stream ciphers. If you use the same key to "protect" two different documents, the keystream drops out when you XOR the two documents together, leaving the plaintexts XOR'd together. The two plain text documents can be recovered using frequency analysis.

How to determine if you're vulnerable
If you use stream ciphers, and you use the same key to protect different streams (or documents), you are at risk.

How to protect yourself

  • Do not use stream ciphers in this fashion
  • Consider using stronger symmetric algorithms such as AES

Weak Algorithms
There is much debate, as numerous 'secure' algorithms have recently been found to be cryptographically weak. This means that instead of taking 280 operations to brute force a cryptographic key, it may only take as little as 269 operations – something achievable on an average desktop.

As modern cryptography relies on being computationally expensive to break, specific standards can be set for key sizes that will provide assurance that with today's technology and understanding, it will take too long to decrypt any given key.


How to determine if you are vulnerable
Proprietary encryption algorithms are not to be trusted as they typically rely on 'security through obscurity' and not sound mathematics. These algorithms should be avoided if possible.

Specific algorithms to avoid:





Cryptography is a constantly changing field. As new discoveries in cryptography are made, older algorithms will be found unsafe. Standard bodies such as NIST should be monitored for future recommendations.


How to protect yourself



The difficulty of cracking a 2048 bit key compared to a 1024 bit key is far, far, far, more than the twice you might expect. Don't use excessive key sizes unless you know you need them. Bruce Schneier in 2002 (see the references section) recommended the following key lengths for circa 2005 threats:

  • Key sizes of 1280 bits are sufficient for most personal applications
  • 1536 bits should be acceptable today for most secure applications
  • 2048 bits should be considered for highly protected applications.




Design your application to cope with new hashes and algorithms:
Include an "algorithmName" or "algorithmVer" attribute with your encrypted data. You may not be able to reverse the values, but you can (over time) convert to stronger algorithms without disrupting existing users.

Key Storage
As highlighted above, crypto relies on keys to assure a user's identity, provide confidentiality and integrity as well as non-repudiation. It is vital that the keys are adequately protected. Should a key be compromised, it can no longer be trusted.


How to determine if you are vulnerable

Can you export the private key or certificate from the store?



How to protect yourself





  • Applications should log any changes to keys.






Insecure transmission of secrets


How to determine if you are vulnerable

  • The encryption algorithm or protocol needs to be adequate to the task. The above chapter on weak keys should be a good starting point




How to protect yourself





Network: below the protocol layer, we can use technologies such as Virtual Private Networks (VPN) to protect data. This has many incarnations, the most popular being IPsec (Internet Protocol v6 Security), typically implemented as a protected 'tunnel' between two gateway routers. Neither the application nor the protocol needs to be crypto aware – all traffic is encrypted regardless.


Reversible Authentication Tokens


How to determine if you are vulnerable
Any deterministic sequence generator is likely to be vulnerable.

How to protect yourself




Unix: For all Unix based platforms, OpenSSL is one of the recommended options (http://www.openssl.org/). It features tools and API functions to generate random numbers. On some platforms, /dev/urandom is a suitable source of pseudo-random entropy.

PHP: mt_rand() uses a Mersenne Twister, but is nowhere near as good as CryptoAPI's secure random number generation options, OpenSSL, or /dev/urandom which is available on many Unix variants. mt_rand() has been noted to produce the same number on some platforms – test prior to deployment.

Do not use rand() as it is very weak.


Safe UUID generation

How to determine if you are vulnerable

  • Determine the source of your existing UUIDS
    1. Did they come from MSDN?
    2. Or from a example found on the Internet?

  • Use your favorite search engine to find out

How to protect yourself


  • Generate fresh UUIDs or GUIDs for each new program


  • Remote access such as IPsec VPN
  • Certificate based authentication
  • Securing confidential or sensitive information
  • Obtaining non-repudiation using digital certificates
  • Online orders and payments
  • Email and messaging security such as S/MIME




Further Reading

Email Alerts


COMMENTS powered by Disqus  //  Commenting policy