Recently, there has been a lot of talk and speculation regarding various cryptographic algorithms that are still widely used. Some security experts suggest banning a number of them; while others argue that some of these algorithms are still secure enough to be used for the time being. No wonder developers remain confused about the choice of which crypto to use in their code.

In order to clarify things, the Fortify Security Research Group (SRG) performed a thorough investigation of the subject. As a result, we came up with a set of guidelines that will be published later this week in the form of a Crypto Manifesto and is available immediately to Fortify customers through the Premium Content area of the Customer Portal. These guidelines cover four of the most critical topics: hash functions, encryption and encoding functions, encryption keys, and pseudo-random number generators (PRNGs). All of the guidelines will be enforced through the most recent version of the Fortify Secure Coding Rulepacks, which were released on February 27th, 2009.

The table below summarizes our guidelines on the usage of crypto in security sensitive contexts:

When it comes to computing hashes on security sensitive data such as passwords, certificates, or any other kinds of digital security credentials where collision and pre-image resistance are important, MD2, MD4, MD5, and SHA-1 are no longer recommended. Collisions have been found in MD2 as early as 1997, while attacks on MD4, MD5, and SHA-1 were demonstrated in 2005. Furthermore, a much more recent research project showed at the end of December 2008 that it is possible to mount a man-in-the-middle attack on Secure Sockets Layer (SSL) via creating rogue certificates issued by rogue Certification Authorities (CAs), only with the help of a homegrown array of machines. Combine this work with Dan Kaminsky's Domain Name System (DNS) problems, and you got yourselves virtually undetectable phishing attacks on the internet.

Similarly to hashing algorithms, a number of encryption algorithms have recently been broken: RC2, RC4, and DES. Worse yet, base64 encoding is mistakenly thought of by many as an encryption scheme. It is important to point out that base64 encoding is useful when there is a need to transmit binary data over a communication channel that is designed to transmit character data. However considering that its character space is only of size 64, the scheme does not provide the same security guarantees as strong cryptographic encryption algorithms, and therefore should not be used for protecting secrets.

In addition to choosing the right encryption algorithm to protect sensitive data, it is important to generate appropriate keys to use with these schemes. Considering that hardware has been getting faster and faster in recent years, choosing appropriate encryption key lengths is becoming increasingly important as the rate at which attackers can make guesses grows. The National Institute of Standards and Technology (NIST) suggests using symmetric keys (particularly, AES keys) of no less than 128 bits in length and RSA keys of no less than 1024 bits, moving towards using 2048-bit keys by 2013. In the case of RSA keys, it is also important to choose the right padding scheme, which can prevent a number of attacks that potentially work against RSA without padding. Public-Key Cryptography Standard (PKCS) #1 v.2.1 recommends the use of Optimal Asymmetric Encryption Padding (OAEP) for new applications.

As for the pseudo-random number generators, when unpredictability is critical, which is the case in security-sensitive contexts, it is important to use strong cryptographic rather than statistical PRNGs. Unlike cryptographic PRNGs, statistical PRNGs produce highly predictable output, which makes it trivial for an attacker to guess the values they generate. However, statistical PRNGs are acceptable when predictability is not a concern - for example, for generating a random order in which images are displayed in a slideshow.

Technorati Tags: hashing encryption base 64 encoding keys PRNGs

Fortify Java Annotations allow developers to give Fortify SCA hints about how their code works, which can prevent both false positives or false negatives. Like custom rules, annotations work by augmenting Fortify's model of the program with additional information and allow for more accurate analysis.

Consider the following code, which loads a password prompt for a login screen, logs it, and returns the loaded string to its caller.

private String loadPasswordLabel() {   String passwordLabel = props.getProperty("passwordLabel");    logger.info("Password label loaded: " + passwordLabel); // false positive!   return passwordLabel; } 

A rule built into the Fortify Secure Coding Rulepacks causes Fortify SCA to guess that the contents of the variable passwordLabel are sensitive because its name contains the string 'password', which causes Fortify SCA to report a false positive privacy violation issue when the variable is written to the log.

The code below demonstrates how Fortify Java Annotations can be used to eliminate this false positive:

private String loadPasswordLabel() {   @FortifyNotPassword String passwordLabel = props.getProperty("passwordLabel");    logger.info("Password label loaded: " + passwordLabel); // no issue reported   return passwordLabel; } 

The @FortifyNotPassword annotation informs Fortify SCA that the variable to which it is applied does not contain a password.

As of Fortify 360 2.0 and the Q1-2009 update to the Fortify Secure Coding Rulepacks, Fortify SCA recognizes the following Fortify Java Annotations:

• Dataflow: Source, Sink, Passthrough, and Validation
• Field and Variable: Password, NotPassword, Private, NotPrivate, NonNegative, NonZero
• Other: Dangerous Class, Method, Field, and Variable and CheckReturnValue

A detailed sample that demonstrates the full capabilities of Fortify Java Annotations is available with supported versions of Fortify 360 and through the Premium Content section of the Customer Portal.

Technorati Tags: annotations java