Great! :)
Thanks, we'll contact you soon.
The 2019 Hiscox Cyber Readiness Report revealed that 61% of firms suffered a cyber-attack in the past year. This was a significant increase from the 45% of companies that suffered attacks in 2018.
In addition, the median cost associated with a cyber incident went up from $229,000 to $369,000. That means there’s a good chance that your business could be hacked.
Due to the growing prevalence of cyber-attacks, software engineers must embrace an unrelenting commitment to application security. Security can’t be an afterthought or treated like an add-on at the end of the design and build process. Teams must ensure that application security not only meets but exceeds current standards–in the U.S., Europe, and beyond.
At Integrant, our team is hyper-focused on security, and we recently worked on a project reiterating the importance of going the extra mile to protect client data.
We were tasked with developing the Java portion of middleware for a mobile app that shared sensitive information with a third-party customer loyalty and engagement program. This presented our team with two Java security challenges:
1: Preventing data from getting hacked while in transit to the third-party program.
2: Protecting the integrity of the third-party data.
In the rest of our article, we'll describe some of our team's tactics while solving a particularly challenging Java integration data security issue.
Regarding application security, several Java integration security best practices and concepts help protect data from unauthorized users. Companies should adopt these best practices to lower the risk of being victim to a serious data breach:
Some Java integration authentication methods ensure that only authorized users have access to a server. Authorized users will have a username and password to verify that they are who they say they are. This may involve single-factor, two-factor, or multi-factor steps. Some companies will even authorize users with retina scans, voice recognition, and fingerprints.
Regarding Java integration encryption techniques, the encryption scrambles sensitive data so that no one except the authorized recipient can read it. Encryption uses an encryption key or a string of characters within an algorithm to alter data.
The encryption can only be unlocked or decrypted by someone with the corresponding key. This prevents cyber criminals and other unauthorized recipients from intercepting and reading communications.
A Java integration security audit log ensures that every action in a system is recorded to track any potential security incidents. As UC Berkeley states, “An effective audit logging program can be the difference between a low impact security incident which is detected before covered data is stolen or a severe data breach where attackers download large volume of covered data over a prolonged period.”
A JSON Web Token (JWT) is a URL-safe, compact, self-contained string. In other words, the token string has been encoded as simple alphanumeric characters. There are three primary parts to a JWT, and you can find the arrangement of the components illustrated below (compliments of Securitum).
You can see that the JWT comprises three long strings of characters separated by a dot and that each element is encoded with the BASE64URL algorithm. The structure of the JWT envelope is as follows: header, payload, and signature.
As we mentioned, our team project involved building a piece of middleware for our client’s mobile app, which would share sensitive data with a third-party customer loyalty and engagement program. The aim was to give customers discounts or incentives (think Starbucks gift cards).
However, it took some trial and error to discover and implement a secure solution to ensure that no customer data ever gets compromised. Here are the Java integration security best practices we adopted in order to “hack-proof” our middleware solution.
The first step was to settle on using JWT to secure the connection between our middleware and the third-party destination. JWT has become the de facto approach to modern Java application integration security, especially within microservice architectures. But as Philippe De Ryck points out, the security properties of JWTs are still largely misunderstood. We also learned that we needed some experience and exposure to test our assumptions.
For example, our team initially aimed to encrypt the data inside a JWT envelope using a public key so the third-party recipient would have a private key to decrypt that data. We discovered that for our public key to be secure enough, it had to be greater than 4,000 bits. This was the only way to guarantee our customer’s information wouldn’t be hacked. On a different note, this also raised a separate issue.
This is where we ran into our first challenge! Performance slows down if you maximize your JWT payload with large amounts of information to avoid querying extra customer information on the backend.
The reason was straightforward: the encryption and decryption processes for the JWT payload and signature require a lot of power. This is especially true if the customer request occurs during “rush hour” or high traffic times. We needed high security for our encryption process but had to do it so that performance wouldn’t suffer.
We were sold on JWT as a solution but needed another way to maximize our payload and securely get back to the drawing board.
To be clear, we tried integrating three systems within a Java environment: the client's mobile application, our middleware solution, and a third-party customer loyalty application.
However, soon into this project, we noticed a significant vulnerability with JWT: even though JWT's content payload cannot be altered, it still can be viewed. This means that if you are storing any sensitive information, it will be exposed to anyone hacking into that communication.
One writer captures the issue this way: Since JWT is "just base64url encoded . . . it is clear that they can be decoded by a base 64 decryption tool. So, JWT does not provide security measures to protect the payload.
If we need to secure the payload of the JWT, we need to configure any security-providing layer to the payload
before the JWT is generated."
In order to guarantee that the JWT payload information is hidden, we encrypted the content of the payload by
applying a synchronous token that is hashed and signed with a private key.
This fulfilled two levels of protection: Not only can the content not be altered because it's hashed and signed by a private key, but the content was now hidden through encryption.
Even with the JWT payload content encrypted and hidden, we still had to take things to another level. The reason was simple: someone who might try to brute force attack the token could eventually figure it out. Once done, the culprit would proceed to decrypt and encrypt all the traffic between the parties they are sniffing. Consider this scenario:
• Imagine 41 is communicating with 42 and sending sensitive information
• Imagine if I can capture the public key of 41
• I can encrypt some garbage information and send it to 42, pretending that I am 41
Because of this vulnerability in JWT, we found it was essential to encrypt the information and sign it with a private key. This way, we could guarantee the specific origin of the one sending the data.
Everything we’ve said so far can be distilled into several underlying principles that should guide your
Java application integration security strategy in general and specifically using JWT.
• There might be a push to build big payloads to minimize extra customer information queries across systems, but this comes with performance tradeoffs.
• Hashing and signing are not heavy performance tasks within a JWT token.
• However, bigger payloads do slow down performance significantly.
• Encryption key length and data length both impact performance as well.
With all the focus today on digital transformation and the competing concerns about innovation, connectivity, speed, agility, and customer experience, business owners must be equally or more vigilant about security. Statistics indicate that an organization may expect at least one data breach in its lifetime, likely more.
Maybe you’re worried about how protected your company data is or unsure where to start implementing application security into your development lifecycle.
At Integrant, security is never left to chance! Topics like authentication, authorization, and JSON Web Tokens are as integral to our development process as functions and loops. Whether you’re in the planning stages or already on the application development path, we can help you develop your end-to-end secure Java integration solutions.
If you’re looking for seasoned enterprise Java developers who are up to date on the latest security trends and Java integration best practices, you’ve come to the right place. We want to work with you! Connect with us today to learn how we can partner together on your next project.
Integrant’s Vision is to transform the software development lifecycle through predictable results.