9 Basic Rules for Using Crypto in Application Development

At its simplest, cryptography (or crypto in nerd parlance) is the study and practice of secure transmission of secrets between two parties, given the presence of a third party. In the wide expanse of information technology systems and applications, crypto forms the foundation of trust for many interactions that require confidentiality. One example is an online banking web application that requires a secure means of transporting the user’s authentication credentials from their web browsers to the back end server that house the bank’s web portal. In such a situation, cryptography must be used to protect any authentication credentials sent over the internet.

The math that makes crypto tick could be quite complex, requiring years of study and practice. Luckily, crypto research has resulted in publicly available algorithms and libraries that meet the demand of most systems or application development activities.

If you are or intend to use any form of crypto in your application, please keep these 9 Basic Rules in mind:

Do Not Roll / Build Your Own Crypto: Do not attempt to build your own cryptographic primitives, encryption schemes or protocols. There are many proven cryptography algorithms and protocols that are continuously scrutinized by cryptographers and mathematicians.
Encrypt all Communication: Data in transit must be protected so attackers cannot read or modify messages. Use encryption by default for all communication between entities on an untrusted channel should be encrypted; if a communication protocol does not support encryption, it should be turned off by default.
Hash All Passwords: Passwords must be stored in such a way that if breached, the value will not be disclosed. The standard way of doing this is through a one way cryptographic function called a hash; a one way function is a mathematically secure way of transforming a value to a fixed length value that cannot be reversed into the original value.
Do not hardcode encryption keys or passwords: Under no circumstance should encryption keys be hardcoded into a system, code, configuration file or other mechanism. Encryption keys must be generated at install time or at time of need.
Protect Secrets and Keys: Secrets within a system must be protected from undesired disclosure. Secrets can include but are not limited to private information, passwords, session information and any private or symmetric key. It is important to know where your secrets are stored, what and who has access to them, how they are used and how they moved.
Utilize Unique Key Encryption Key (KEK) for handling and protecting numerous encryption keys: Juggling numerous encryption and private keys within a system, keeping track of their storage locations and making sure each key is protected can be challenging. All stored keys should be encrypted with a single key (KEK) this leaves only one piece of data that needs to be carefully protected.
Sign All Released Software Binaries or Images: If you provide software images or binaries to your customers; they should be able to verify that the artifacts received have come from you and have not been modified by attackers. Image signing and verification provides a root of trust that the item(s) received are from a known, valid and in some cases, trusted source.
Use Safe Crypto Libraries: Whenever you use third-party software libraries to implement crypto, select libraries hat have undergone significant review, from known, trusted security experts. Such projects are also actively maintained, leading to timely fixes of any vulnerabilities discovered.
Use Cryptographically Strong Random Number Generators: Most computer systems do not offer truly random number generation but approximate randomness through various Pseudo-Random Number Generators (PRNG). Poor selection of random numbers creates weaknesses in cryptography and session identifier protections. Research generators for your OS and/or programming language are considered cryptographically secure.