When information security professionals / Administrator / Manager talk about insecure cryptography, they’re usually referring to vulnerabilities around insecure cryptography and rarely talking anything about mathematics, or breaking cryptography.

Naturally, issues revolve around clear-text communication and insecure storage of sensitive data considering the current threat landscape. The past many years have seen several large scales hacks around stolen user databases where passwords were stored in plain-text or another easily disclosed format. These issues can easily be avoided by using countermeasures like cryptography and fixing vulnerabilities around it.

The legacy of clear-text communication protocols

Clear-text communication means data is sent without any sort of encryption. And although modern web protocols can encrypt an entire website rather than just a couple of sensitive pages, clear-text communication is still a serious issue for applications that handle sensitive information on the cyberspace.

As applications become more complex, more data is being transmitted through HTTP requests, increasing the risk that someone can intercept that data, or simply come across unencrypted transmissions that have been stored for too long. Also, many types of data that are at risk due to clear-text transmission are session IDs, cookie data, form data, and transactional information.

Insecure storage

Many modern applications also store data insecurely on the back end database or storage. Even though most applications use SSL or HTTPS encryption over the Internet/networks, user credentials might be stored in back-end systems without any encryption. This leaves passwords vulnerable to attackers to many attacks.

The weak storage of passwords and other sensitive data is an issue that has been widely reported. And developers should be educated and encouraged to take all necessary precautions when storing data securely in the backend systems.

Countermeasures

While considering the subject of this article it is difficult to cover cryptography in detail. Still, let’s take a look at how we can use strong cryptography in applications to address the risks.

Data sensitivity

A mature process around data classification and handling is must, though developers also need to have a good understanding of data that will be processed, stored, or transmitted by the application before considering the encryption method for it.

Web applications have a specific category of data that must be protected in any case such as passwords, session IDs, cookie data, etc. while other data which belongs to services being provided by application such as Form data, published or transacted contents like audios, videos, text etc. which may be subject to sensitivity of the data. And level of sensitivity of data will guide to determine how to protect it.

Cryptography

Speaking in basic language, Cryptography produces ciphertext, or encrypted information, that’s difficult to break and analyze by attackers who gain access to information by some method. Cryptography have below 3 components in its process of encrypting information:

• Sensitive data
• Algorithms
• Protecting keys

Sensitive Data

Up to the extent possible sensitive data should not be stored. If application have exclusive requirement to store sensitive data, than disable caching, encrypt the data, and never store it in plain text. If you’re storing encrypted data using one-way hashes, make sure to add a salt to them to prevent any automated attacks against it. Strong salted hashing functions include Argon2, scrypt, bcrypt, and PBKDF2.

Algorithms

Always, don’t use algorithms that have known weaknesses, and never try to develop your own new or customized encryption algorithms, use cryptographically strong APIs provided by your programming language because these have been thoroughly tested.

Key management

Use cryptographically strong random number generators to create private keys. Avoid pseudo-random, or weak, generators because they might be unscrambled by attackers. Also, having a strong key management is essential, which need strong policies. It should be make sure that clear and well-defined policies for securing key creation, rotation, destruction, and controlling access are established, implemented and reviewed as per industry best practices.

Transport layer security

To protect confidentiality on the Internet use Transport Layer Security, or TLS, a type of network layer security also known as SSL and HTTPS. TLS is the accepted standard for encrypting data in transit presently. Be mindful that web traffic is unencrypted by default, so any attacker can intercept and misuse it unless it’s protected. For sites that handle very sensitive data, HTTP should be disabled, and HTTPS should be used site-wide.

To make the most use out of TLS encryption, disable any ciphers that use anything under 128-bit encryption, because they aren’t complex enough for today’s hackers. Also, remove v1, v2, and v3 versions of SSL because they have known vulnerabilities.

Finally, use TLS with Perfect Forward Secrecy (PFS) ciphers, cipher prioritization, and secure parameters. PFS ciphers frequently create new keys to prevent past sessions from being compromised if any keys or passwords are compromised in the future.

Challenges to hashing

Hashing is not foolproof method. Hackers can use look-up tables (Rainbow Table Attack) that list pre-generated hashes with their original values. This way, commonly used passwords can be discovered by matching them against look-up lists, nullifying the protection hashing provides.

Sr. NO	User ID	Password	Password Hash
1101	Albert	P@ssw0rd	161ebd7d45089b3446ee4e0d86dbcf92
1102	Pinto	Lrjo#765	809199c18294512174bc7f11c6d0503d
1103	Vijay	123456	e10adc3949ba59abbe56e057f20f883e
1104	Rakesh	123456	e10adc3949ba59abbe56e057f20f883e
1105	Priya	123456	e10adc3949ba59abbe56e057f20f883e

In above example, if a hacker is able to get their hands on a list of hashed passwords, they could easily see that these three users have the same password.

Salts

Weaknesses in hashing can be overcome by adding salt on hashes. Salting a hash adds some random data to the original information so that it doesn’t always produce the same output. By making sure that each password is salted in a different randomized way, two identical passwords will never be hashed to the same value.

This way, we end up with a salted hash that doesn’t resemble anything on a look-up table of hashes attackers might use to steal account information.

Key Takeaway from the article

• Don’t Store sensitive information, if it cant we avoided than use cryptography to protect it.
• Use strong cryptographic algorithms that have been proven and tested by the industry instead of trying to invent your own.
• key management is a difficult process, so make sure you have people, policy and technology in place to protect it and manage keys securely.