5 Things We Learned About Java Integration Security and Why It Matters
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 at some point.
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 that reiterated 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 which 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 and
2: Protecting the integrity of the third-party data.
In the rest of our article, we’ll describe some of the tactics our team used while solving a particularly challenging Java security integration issue.
For more information about Java integration security, Check out our blog
Basics of Application Security
When it comes to application security, there are a number of best practices and concepts that help protect data from unauthorized users. Companies should adopt these best practices to lower the risk of being victim to a serious data breach:
Authentication
Authentication is used to 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 use retina scans, voice recognition, and fingerprints to authorize users.
Encryption
Encryption scrambles sensitive data so that no one except the authorized recipient can read it. Encryption works through use of an encryption key or a string of characters within an algorithm for altering 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.
Logging
A 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 of time.”
JSON Web Token
A JSON Web Token (JWT) is an URL-safe, compact, and 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 is comprised of 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.
Looking for the right fit to extend your software team? Check out our services!
Our Security Solution
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 provide customers with discounts or incentives (think Starbucks gift card).
However, it took some trial and error for us to discover and implement a secure solution to ensure that no customer data ever gets compromised. Here are the best practices we adopted in order to “hack-proof” our middleware solution.
1. JWT is the “Key” to Sharing Sensitive Information
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 application security, especially within microservice architectures. But as Philippe De Ryck points out, the security properties of JWTs are still largely misunderstood. As we also found out, we needed some experience and exposure to test out our assumptions.
For example, our team originally 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 4000 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...
2. Watch Your Performance
This is where we ran into our first challenge! If you maximize your JWT payload with large amounts of information to avoid querying extra customer information on the backend, performance slows way down.
The reason was straightforward: the encryption process and the decryption process for the JWT payload and signature requires a lot of power. This is especially true if the customer request comes in during “rush hour,” or high traffic times. We needed high security for our encryption process but had to do it in the way that performance wouldn’t suffer.
We were sold on JWT as a solution, but we just needed another way to securely maximize our payload. Back to the drawing board.
3. Encrypt JWT Content Payloads
To be clear, we were trying to integrate three systems together within a Java environment: the client’s mobile application, our middleware solution, and third-party customer loyalty application. However, soon into this project we noticed a significant vulnerability with JWT: even though the content of JWT payload cannot be altered, it still can be viewed. This means that if you are storing any sensitive information, it will be exposed for anyone hacking into that communication.
One writer captures the issue this way: Since JTW 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 kind of 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 the content cannot be altered because it’s hashed and signed by a private key, the content was now hidden through encryption.
4. Don’t Just Encrypt, but Sign Your Keys
Even with the JWT payload content encrypted and hidden, we still found that we 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 then 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 important to not just encrypt the information but sign it with a private key. This way we could guarantee the specific origin of the one sending the information.
5. Pay Attention to Your Payload
Everything we’ve said so far can be distilled into several underlying principles that should guide your application security strategy in general and specifically using JWT.
- There might be a push to build big payloads in order 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.
Looking for an extended Java team that’s the cheese to your macaroni?
Next Steps
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, and likely more.
Maybe you’re worried about how protected your company data really is, or unsure of 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 well along on the path of application development, we are ready to help you develop your end-to-end security solution.
If you’re looking for seasoned enterprise Java developers, who are up to date on the latest security trends and best practices, then 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.
Related Content
We developed an efficient Agile working environment for our distributed dev teams located in 3 different countries, and you can read more here.
We built a custom recommendation engine from scratch using Java and several other technologies. Click the link to learn how we did it.
Subscribe to our newsletter!
We've been in the software industry for 30+ years so we have a lot to share with you!
Follow US
Address: 16870 W Bernardo Dr, Suite 250
San Diego, CA 92127
Email: info@integrant.com
Phone: +1 858.731.8700
© 2021 Integrant, Inc. All Rights Reserved