Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: Using java.util.Random to generate XIDs for distributed transactions is not secure enough #40262

Closed
gabilang opened this issue Apr 20, 2023 · 4 comments · Fixed by #40269
Assignees
Labels
Team/jBallerina All the issues related to BIR, JVM backend code generation and runtime Type/Bug

Comments

@gabilang
Copy link
Contributor

Description

In

using java.util.Random does not provide sufficient security for the applications which are needed high assurance. We can use java.security.SecureRandom instead.

Steps to Reproduce

No response

Affected Version(s)

No response

OS, DB, other environment details and versions

No response

Related area

-> Runtime

Related issue(s) (optional)

No response

Suggested label(s) (optional)

No response

Suggested assignee(s) (optional)

No response

@ballerina-bot ballerina-bot added the Team/jBallerina All the issues related to BIR, JVM backend code generation and runtime label Apr 20, 2023
@gabilang gabilang self-assigned this Apr 21, 2023
@Nadeeshan96
Copy link
Contributor

@gabilang Are we considering a security purpose here

? It seems this is used to generate a random unique ID. So it may not be necessary to change it. Using SecureRandom is slower (can say roughly 10x or 20x) than Random and use higher memory. Anyway we can do this change to mitigate the warning.

@gabilang
Copy link
Contributor Author

A transaction ID is used to uniquely identify a transaction and is often used for logging, auditing, and tracking purposes. In addition, transaction IDs may be used to ensure that transactions are executed in the correct order or to prevent duplicate transactions from occurring. It's important that transaction IDs are secure to prevent unauthorized access or tampering with sensitive data. An attacker who is able to guess or predict a transaction ID could potentially access or modify sensitive data, impersonate a user, or perform other unauthorized actions. For example, if a transaction ID is simply a sequential number, an attacker could guess the next ID in the sequence and create a fake transaction that would be accepted by the system.

To ensure the security of transaction IDs, they should be generated using a secure random number generator, Java provides SecureRandom class for this purpose. This ensures that the IDs are unpredictable and resistant to guessing or prediction attacks.
There is always a trade-off between security and speed in generating transaction ids. It's not desirable to compromise security for higher performance in distributed transaction cases.

@Nadeeshan96
Copy link
Contributor

Thanks a lot for the clarification!

@github-actions
Copy link

github-actions bot commented May 4, 2023

This issue is NOT closed with a proper Reason/ label. Make sure to add proper reason label before closing. Please add or leave a comment with the proper reason label now.

      - Reason/EngineeringMistake - The issue occurred due to a mistake made in the past.
      - Reason/Regression - The issue has introduced a regression.
      - Reason/MultipleComponentInteraction - Issue occured due to interactions in multiple components.
      - Reason/Complex - Issue occurred due to complex scenario.
      - Reason/Invalid - Issue is invalid.
      - Reason/Other - None of the above cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team/jBallerina All the issues related to BIR, JVM backend code generation and runtime Type/Bug
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants