Data security has always been on the to-do list for software providers, especially for those who place an emphasis on user privacy. Between 2017 and 2018, the average cost of cybercrime for each company affected grew from $11.7 million to $13 million according to The Cost of Cybercrime: Ninth Annual Cost of Cybercrime Study conducted by the Ponemon Institute and jointly developed by Accenture. Data breaches also affect a company’s reputation, which results in customer churn and business damage.
For instance, American Medical Collection Agency (AMCA), a US medical debt collector, recently faced a massive data breach. Cybercriminals captured the personal, financial, and medical data of over 25 million patients who had used AMCA’s digital payment portal. As a result, the company lost several major clients within a month, nearly 80 percent of employees lost their jobs, and AMCA’s CEO took out a personal loan for $2.5 million to cover the costs of notifying customers affected by the incident. Ultimately, the consequences of this breach led AMCA to file for chapter 11 bankruptcy.
The chart below, taken from The Cost of Cybercrime, represents the major consequences of cyberattacks. It shows that the average annual cost as a result of information loss (theft), which amounted to $5.9 million in 2018, is growing faster than the cost of other consequences of attacks.
These sad statistics show that digital businesses should take adopting effective data protection strategies seriously. We’ll share some basic knowledge of data security technologies in this guide to data protection.
A cyberattack in a nutshell
A cyberattack is a malicious attempt to attack a computer information system or a personal digital device with the intent to gain unauthorized access to a specific asset (for example, sensitive user information) to then steal, alter, destroy, or publicly expose it. Often, an attacker seeks financial benefit from invading a victim’s system.
To ensure maximum esecurity when exchanging data, you should start with estimating risks your company might face. Early in the development life cycle, threat modeling will help you define security concerns related to the system architecture and design. Later, you can spot security problems by means of code reviews or penetration testing. If you don't do enough testing, issues might not be revealed until the app is in production and is compromised.
Read also: Code Review Via GitLab Merge Requests
How to use OWASP to estimate the gravity of cybersecurity risks
By following the OWASP Risk Rating Methodology, you can assess the severity of all cybersecurity risks and make an informed decision about what actions to take in response to those risks. A system for rating risks will help you save time and ensure that you don’t get distracted by minor risks while neglecting critical risks that are less well understood.
A universal risk rating system will properly assess all the risks your company faces. Note that a vulnerability that’s crucial for one business might not be crucial for another. Therefore, you should customize the basic framework shown below for your company.
After performing a risk assessment, you might determine, for example, that there’s a need for HTTPS inspection. In that case, you’ll have to ensure your HTTPS inspection products are providing appropriate Transport Layer Security (TLS) certificate validation. Products that don’t provide secure TLS communications and don’t transmit error messages to the user are likely to affect the end-to-end protections that HTTPS is designed to ensure.
Why serve a website via HTTPS?
HTTPS (HyperText Transfer Protocol Secure) is also called HTTP over TLS or HTTP over SSL. Sites that are served via HTTPS have redirects, meaning that even if you enter http://, you’ll automatically be redirected to a secure, encrypted https:// connection. TCP (Transmission Control Protocol) helps HTTPS to forward and receive data packets. This happens via port 443 using a connection encrypted by TLS.
The basis of HTTPS is public/private-key cryptography. The public key is for encryption. The private key is secret. It’s required for decryption. Both keys are randomly generated and stored in your server.
A Certificate Authority, or CA, cryptographically signs digital certificates. All browsers have a list of CAs they trust. Certificates signed by a CA in the browser’s list are indicated with a green padlock in the browser’s address bar as they are trusted and belong to the domain. Services like Let’s Encrypt have made obtaining SSL certificates free.
How TLS/SSL helps the HTTPS protocol and connected components protect data
As a rule, a man-in-the-middle (MITM) attack intercepts HTTP session cookies to steal a user’s authenticated session and act like that authenticated user. The use of encryption methods like Wi-Fi Protected Access (WPA) and other local solutions can complicate such an attack. However, if a site doesn’t require end-to-end HTTPS, an MITM attack still might be successful.
TLS/SSL helps the HTTPS protocol ensure the protection of data when transmitting it over the internet. Appropriate use of the protocol ensures that the data received by the client is encrypted and cannot be read by any third party. We can also use TLS/SSL for securely connecting components such as microservices with a database or a load balancer.
If a mobile app doesn’t use SSL, which is often the case, the app connects, authenticates, and transmits data via the network in the form of cleartext. An MITM attack is able to capture this data. If an app uses SSL but doesn’t verify the SSL certificate correctly, the app becomes susceptible to a man-in-the-middle SSL attack.
HTTPS is good but is not enough
As secure HTTPS gets increasingly common, it begs the question: Why encrypt your data end to end if HTTPS provides a high level of security? Well, the thing is that HTTPS is an essential but still only a small component of the cryptography puzzle. To find out what extra security requirements your company needs, answer the following questions:
- How many times does your data get decrypted and re-encrypted while traveling from a user to your system?
- How many systems can access the cleartext during transmission?
- How many departments are responsible for this data journey?
After answering these questions, note the limitations of HTTPS and the benefits end-to-end encryption provides.
What are the limitations of HTTPS?
HTTPS gives the impression that data is encrypted, but it’s not that simple. HTTPS doesn't encrypt data at rest. This harms the security of both sides of the transmission process.
Additionally, HTTPS absolutely ignores what happens to the data once the HTTPS connection is terminated, which might happen farther out on the edge of your network than you think (for example, at your load balancer).
This creates a vulnerability, making it possible for you to be attacked at various points of processing (application, load balancer, server), two points of storage (mobile, server), and one point of transmission (internal traffic).
If your server is the endpoint of your web API but your services for processing, analyzing, sharing, and backing up data are different points, the situation gets worse. In this case, you use HTTPS, but you can’t confirm that you’ve encrypted the data which makes it unprotected. In the case of end-to-end data encryption, data is secure at all points of transmission.
So how can we further secure the communication between our users?
End-to-end encryption best practices to provide secure communication between users
So far, end-to-end encryption is considered the most secure method for exchanging data online. This technology allows for encrypting messages at both ends of a conversation (the sender and the recipient). Such an approach prevents someone in the middle (a hacker, a government, or a service provider) from accessing private information. The trick with end-to-end encryption is that no one except for the sender and the recipient has the private key needed to decrypt the messages.
For many systems that we use in day-to-day life – such as email services and online chats – encrypted messages may still pass through a company’s servers, where they’re decrypted and stored before being delivered to the recipient. This poses a real risk of users’ private information being read or misused if a service provider’s server is poorly protected.
End-to-end encryption is considered safer, as it minimizes the number of parties involved in the data encryption process (and who may be attacked). With end-to-end encryption, a service provider’s server only works to pass messages, while the actual encryption/decryption procedure happens on users’ devices.
How does end-to-end encryption work?
Asymmetric encryption, a more modern implementation of end-to-end encryption, uses a pair of keys (large numerical values) to make secure communication possible:
- A public key is used to encrypt data transferred from a sender to a recipient. The public key is usually generated by a service provider and is available through a public directory to anyone who wants to send encrypted messages.
- A private key is used to decrypt the contents of a message encrypted with the public key; only the recipient has the private key to unlock the message.
Say you want to message “What’s up?” to your friend Nicole in private, using a secure end-to-end encrypted messenger. To do so, you’re going to use Nicole’s public key to encrypt your message and turn it into so-called ciphertext.
You’ll then send your encrypted message over the public internet. On its way, your message can pass through a number of the messenger’s servers. Still, the messenger itself won’t be able to turn your ciphertext into plaintext to read it. Only Nicole with her private key can do so.
Another look at the use of end-to-end encryption: non-messaging use cases
End-to-end encryption makes sense whenever two parties exchange sensitive data. Use cases include not only direct messaging but email communication, remote desktop access, and online banking.
Let’s look at this in terms of payment gateways. How to protect credit card information? When a user enters such information at the checkout, this data is instantly encrypted and stays encrypted until it reaches a payment processor or an acquirer, where it gets decrypted.
Implementing end-to-end encryption doesn’t necessarily require you to have expensive equipment or training — or to hire many technical specialists.
Keep in mind that reputable payment systems like PayPal encrypt card information themselves. PayPal, for instance, tracks all transactions around the clock to avoid fraud, email phishing, and identity theft. Retailers can’t access card information as long as they’re using PayPal’s Vault API, as each transaction is encrypted. The Vault API securely stores users’ card data so a retailer doesn’t need to keep that data on their servers.
Read also: Mobile App Payment Gateway Integration
Yalantis’ experience with end-to-end encryption
At Yalantis, we’ve solved the problem of encryption and decryption for group chats.
To establish encrypted connections, we generate all needed keys when the chat is created to ensure secure message encryption. In order to gain additional network security, all keys are generated per chat, meaning that keys generated for chat A are useless for chat B.
Also, there are no general or app-wide keys or certificates. Key generation and propagation across all chat members (participants) happens in the following way:
Despite the strength of the encryption algorithm, exchanging keys is a challenge. We already know that encryption keys must only be known to the communicating parties. So how can we ensure such a level of privacy? With the help of a secure communication channel established by the Diffie-Hellman algorithm. Let’s check how we use it.
The role of the Diffie-Hellman algorithm in ensuring secret key exchange
The Diffie-Hellman algorithm was one of the first famous asymmetric key implementations, and it’s mainly used for key exchange. Symmetric key algorithms are fast and secure, but exchanging keys is always challenging.
You need to find a way for all systems to receive the private key, and the Diffie-Hellman algorithm helps with this. It’s used to set up a secure communication channel that is then used by the systems to exchange a private key, which is then used to ensure symmetric encryption between the systems.
At Yalantis, we also apply Curve25519, an elliptic curve providing 128 bits of security that’s specially designed to be used with the Diffie-Hellman elliptic curve. We’ve used Curve25519, XSalsa20, and Poly1305 as encryption/decryption/message verification algorithms. Android, iOS, and Golang, which we use for backend development, all have native libraries for these three algorithms.
For example, NaCL is an algorithm for multiple languages. In Golang, Yalantis is using a Package Box that authenticates and encrypts small messages by means of public-key cryptography. The Package Box uses Curve25519, XSalsa20, and Poly1305 to encrypt and authenticate messages.
Using NaCl to create cryptographic tools
NaCl (read as “salt”) is a fast and easy-to-use software library tailored to network communication, encryption, decryption, and signatures. It provides all operations necessary to create great cryptographic tools. Here are the features of NaCl:
Data-dependent branches. The CPU’s instruction pointer and branch predictor are not tailored to keeping data secret. The history of cybercrime has lots of examples of successful timing attacks that have captured secret keys from these CPU components. NaCl avoids the flow of secret information to the instruction pointer and the branch predictor. There are no conditional branches based on secret information; each loop count is predictable. Such protection is compatible with high speed. Therefore, there’s no sense considering options that provide weaker protections.
Data-dependent array indices. The CPU’s cache and translation lookaside buffer (TLB) are also not tailored to keeping addresses secret. Some successful cache timing attacks have used secret data leaked via addresses. NaCl avoids all flows of secret data to addresses applied in load and store instructions. There are no array lookups with indices based on secret data, and the pattern of memory access is predictable.
No dynamic memory allocation and copyright restrictions. C NaCl is intended to be usable in environments that cannot guarantee the availability of large amounts of heap storage but that nevertheless rely on their cryptographic computations to continue working. C NaCl functions do not call malloc, sbrk, etc. They do use small amounts of stack space, which we will eventually measure using separate benchmarks. This feature applies only to C NaCl. Higher-level languages such as Python are not currently usable in restricted environments. All NaCl software is in the public domain.
The best you can do to achieve maximum security is to apply cryptographic standards that are likely to be relevant for the next five to ten years. Closely following NIST guidelines helps Yalantis find the most relevant solutions that have already proven efficient. For example, Realm has its own cryptographic mechanisms that we apply to the apps we develop.
There are multiple effective ways of protecting and securing data including encryption, strong user authentication, backups, and erasure. All of them are worth independent articles. In this post, we tried to distill the mandatory components of a cybersecurity barrier.
Note that you can always rely on professionals to implement security measures specific to your business. After a massive 2016 data breach, Uber needed to hire an outside firm to conduct an assessment of their data security solutions and then implement those recommendations to tighten their security. This step was aimed at establishing methods to safeguard user data stored on third-party platforms and to build strong password-protection policies.