The failure to encrypt data passes up the guarantees of confidentiality, integrity, and accountability that properly implemented encryption conveys.
Omitting the use of encryption in any program which transfers data over a network of any kind should be considered on par with delivering the data sent to each user on the local networks of both the sender and receiver.
Worse, this omission allows for the injection of data into a stream of communication between two parties - with no means for the victims to separate valid data from invalid.
In this day of widespread network attacks and password collection sniffers, it is an unnecessary risk to omit encryption from the design of any system which might benefit from it.
The Encryptor interface provides a set of methods for performing common encryption, random number, and hashing operations.
Following ESAPI encryption & decryption methods are used in the Encryption lab:
Encryption & decryption using ESAPI's encryptor interface can be done as follows:
String decrypted = "Unencrypted text";
PlainText plainText = new PlainText(decrypted);
CipherText cipherText = ESAPI.encryptor().encrypt(plainText);
plainText = ESAPI.encryptor().decrypt(cipherText);
decrypted = plainText.toString();
seal = ESAPI.encryptor.seal( plaintext, instance.getTimeStamp() + 1000 * Integer.parseInt(timer) );
boolean verified = ESAPI.encryptor.verifySeal( toVerify );
plaintext = ESAPI.encryptor.unseal(sealed);
Insecure randomness errors occur when a function that can produce predictable values is used as a source of randomness in security-sensitive context.
Computers are deterministic machines, and as such are unable to produce true randomness. Pseudo-Random Number Generators (PRNGs) approximate randomness algorithmically, starting with a seed from which subsequent values are calculated.
There are two types of PRNGs: statistical and cryptographic. Statistical PRNGs provide useful statistical properties, but their output is highly predictable and forms an easy to reproduce numeric stream that is unsuitable for use in cases where security depends on generated values being unpredictable. Cryptographic PRNGs address this problem by generating output that is more difficult to predict. For a value to be cryptographically secure, it must be impossible or highly improbable for an attacker to distinguish between it and a truly random value. In general, if a PRNG algorithm is not advertised as being cryptographically secure, then it is probably a statistical PRNG and should not be used in security-sensitive contexts.
Examples:
The following code uses a statistical PRNG to create generate a pseudo-random number.
int GenerateRandomNumber() {
Random ranGen = new Random();
ranGen.setSeed((new Date()).getTime());
return (ranGen.nextInt(400000000));
}
This code uses the Random.nextInt() function to generate "unique" identifiers for the receipt pages it generates. Because Random.nextInt() is a statistical PRNG, it is easy for an attacker to guess the strings it generates. Although the underlying design of the receipt system is also faulty, it would be more secure if it used a random number generator that did not produce predictable receipt identifiers, such as a cryptographic PRNG.
The Randomizer interface defines a set of methods for creating cryptographically random numbers and strings. Implementers should be sure to use a strong cryptographic implementation, such as the JCE or BouncyCastle. Weak sources of randomness can undermine a wide variety of security mechanisms.
ESAPI's Randomizer Interface includes following functions:
java -classpath esapi-2.0.1.jar;log4j- 1.2.16.jar org.owasp.esapi.reference.crypto.JavaEncryptor