search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.16k stars 598 forks source link

Support AES-256 password encoding In Liberty #29659

Open Zech-Hein opened 2 months ago

Zech-Hein commented 2 months ago

Description

Open Liberty does not currently support AES-256 password encoding. Only AES-128 byte password encoding is currently supported. Customers would like to use AES-256 for stronger password encoding.

Documents

When available, add links to required feature documents. Use "N/A" to mark particular documents which are not required by the feature.

General Instructions

The process steps occur roughly in the order as presented. Process steps occasionally overlap.

Each process step has a number of tasks which must be completed or must be marked as not applicable ("N/A").

Unless otherwise indicated, the tasks are the responsibility of the feature owner or a delegate of the feature owner.

If you need assistance, reach out to the OpenLiberty/release-architect.

Important: Labels are used to trigger particular steps and must be added as indicated.

Prioritization (Complete Before Development Starts)

The OpenLiberty/chief-architect and area leads are responsible for prioritizing the features and determining which features are being actively worked on.

Prioritization

Design preliminaries determine whether a formal design, which will be provided by an Upcoming Feature Overview (UFO) document, must be created and reviewed. A formal design is required if the feature requires any of the following: UI, Serviceability, SVT, Performance testing, or non-trivial documentation/ID. Furthermore, each identified item places a blocking requirement on another team so it must be identified early in the process. The feature owner may check-off the item if they know it doesn't apply, but otherwise they should work with the focal point to determine what work, if any, will be necessary and make them aware of it.

Design Preliminaries

Design

No Design - NA

FAT Documentation

A feature must be prioritized before any implementation work may begin to be delivered (inaccessible/no-ship). However, a design focused approach should still be applied to features, and developers should think about the feature design prior to writing and delivering any code.
Besides being prioritized, a feature must also be socialized (or No Design Approved) before any beta code may be delivered. All new Liberty content must be inaccessible in our GA releases until it is Feature Complete by either marking it kind=noship or beta fencing it.
Code may not GA until this feature has obtained the Design Approved or No Design Approved label, along with all other tasks outlined in the GA section.

Feature Development Begins

Legal and Translation

In order to avoid last minute blockers and significant disruptions to the feature, the legal items need to be done as early in the feature process as possible, either in design or as early into the development as possible. Similarly, translation is to be done concurrently with development. All items below MUST be completed before beta & GA is requested.

Innovation (Complete 1 week before Beta & GA Feature Complete Date)

Legal (Complete before Beta & GA Feature Complete Date)

Translation (Complete by Beta & GA Feature Complete Date)

In order to facilitate early feedback from users, all new features and functionality should first be released as part of a beta release.

Beta Code

Beta Blog (Complete by beta eGA)

A feature is ready to GA after it is Feature Complete and has obtained all necessary Focal Point Approvals.

Feature Complete

Focal Point Approvals (Complete by Feature Complete Date)

These occur only after GA of this feature is requested (by adding a target:ga label). GA of this feature may not occur until all approvals are obtained.

All Features

Design Approved Features

Remove Beta Fencing (Complete by Feature Complete Date)

GA Blog (Complete by Friday after GM)

Post GM (Complete before GA)

Post GA

yasmin-aumeeruddy commented 1 month ago

Slide 4. Question: Are we looking to extend support for other attributes? Answer: Yes there are issues currently open.

Slide 12: Question: Are you referring to the performance of encryption or decryption? Answer: Both encryption and decryption. The part that matters for the Liberty server is the decrypting which happens one time at server start up or if you have a configuration update with the password.

This AES prefix, it's the same for both? Do you differenciate with the length? The diffenciation for the string is from the actual value of the string when you decode it into a byte array. The first byte's value is a 0 for AESv0 but the new version will have a 1.

Question: Are the terms AESv0 AESv1 for internal use or external use? Answer That is internal use. It's not even shown in the documentation

Slide 13 : Question: Are you leaving a backdoor to carry on allowing us to encrypt using AES-128.
Answer: We do not plan on providing this. If needed, older versions of Liberty can be used.

Question: Will 256 be adequate to meet current standards? Answer: Yes, even 128 is adequate but no one has expressed interest in 128.

Slide 18: Question: When you use securityUtility in code, we have -key that is not the actual key value. It may be confusing. Answer: The parameter is just the string for the password used to derive the key value.

Question: It might introduce confusion where the user may update to the latest version of Liberty and run the same command with the same key but get a different value. It is unlikely that a customer would care about this. Answer: Even if a customer would run the same password with the 128, they would get a different bytes anyway.

Question: Is this all transparant to the users? Answer: Yes, it will be transparant. A lot of customers have been asking about this. They would also notice that when they run the same commands, the actual values are longer.

Question: Is there a flow outside of our runtime, via the API or utility where these AES strings are encoded or decoded? Answer: There are no developer toolings that would have its own way of doing this without calling these APIs. It may be worth checking this with the developer teams though.

Notes: Missing -- before key Missing quotations around the API decryption example value.

Slide 22: Concern - There was a time when the jvm wouldn't allow certain security algorithms before checkpoint. We put a restore hook into authDataImplementation to delay the decryption for the auth data at restore. This may be okay for auth data. However, if it is called after checkpint they may get an NoSuchFound algorithm exception. We are unsure if 128/256 decryption has been tested for checkpoint. We need to check that.

Slide 28: Concern- The impact on Paris needs considering: Encrypted values in files and secrets are mounted into the Liberty pod as it starts. The Liberty instance that runs the customer's instance is not the same. The versions may not align and AES-128 may be used with the customer's instance but not supported by the Liberty instance. We need to ensure that the version of Liberty that runs the rest api feature is consistent for Paris.

Slide 29: Question: Why are we comparing the 256 with 512? Answer: For AESv1, we are planning to use the PBKDF2WithHmacSHA512 algorithm.

Question? Does the number of encypted passwords matter?
Answer: No it doesn't matter. There is a one time cost.

Question: Is it the same cost with decryption? Answer: Yes. The cost comes from getting the algorithm implementation loaded.

Slide 30: Note: It would be worth noting the Paris concerns here (See above)

Zech-Hein commented 4 weeks ago

UFO Review changes slide 18: I fixed the --key slide 30: I added the Paris concern about liberty versions being different

Zech-Hein commented 3 weeks ago

Beta PR: https://github.com/OpenLiberty/open-liberty/pull/30049

NottyCode commented 2 weeks ago

Slide 12: Question: Are you referring to the performance of encryption or decryption? Answer: Both encryption and decryption. The part that matters for the Liberty server is the decrypting which happens one time at server start up or if you have a configuration update with the password.

This isn't correct. We only generate the encryption key once on startup, but how often the password is decrypted will depend on how the runtime that consumes that password. Best practice would be to keep it encrypted except when the decrypted form is needed. However we do not enforce it. The ConfigAdmin version will always be encrypted and the consumer of that has to decrypt, so it depends on how often the consumer goes back to the string in ConfigAdmin.

Slide 22: Concern - There was a time when the jvm wouldn't allow certain security algorithms before checkpoint. We put a restore hook into authDataImplementation to delay the decryption for the auth data at restore. This may be okay for auth data. However, if it is called after checkpint they may get an NoSuchFound algorithm exception. We are unsure if 128/256 decryption has been tested for checkpoint. We need to check that.

This says we need to check this, but I do not see it being addressed in the comment or the UFO.

Slide 28: Concern- The impact on Paris needs considering: Encrypted values in files and secrets are mounted into the Liberty pod as it starts. The Liberty instance that runs the customer's instance is not the same. The versions may not align and AES-128 may be used with the customer's instance but not supported by the Liberty instance. We need to ensure that the version of Liberty that runs the rest api feature is consistent for Paris.

I do not follow this. We are not removing support for AES-128 so if a customer has AES-128 encrypted passwords they would be correctly decrypted by Liberty. Perhaps there is impact on whatever Paris is where it would want to use AES-256, but that would just require Paris to update to a newer Liberty.

Question? Does the number of encypted passwords matter? Answer: No it doesn't matter. There is a one time cost.

This is not correct. It is a one time cost to generate the encryption key, but not to decrypt passwords. If you have 1 encrypted password it'll be faster than 100.

Zech-Hein commented 2 weeks ago

Slide 12: Question: Are you referring to the performance of encryption or decryption? Answer: Both encryption and decryption. The part that matters for the Liberty server is the decrypting which happens one time at server start up or if you have a configuration update with the password.

This isn't correct. We only generate the encryption key once on startup, but how often the password is decrypted will depend on how the runtime that consumes that password. Best practice would be to keep it encrypted except when the decrypted form is needed. However we do not enforce it. The ConfigAdmin version will always be encrypted and the consumer of that has to decrypt, so it depends on how often the consumer goes back to the string in ConfigAdmin.

Good point, that is an important distinction to make. I will update slide 29: Performance - The encryption key is derived one-time at startup. Frequency of password decryption will depend on the runtime.

Slide 22: Concern - There was a time when the jvm wouldn't allow certain security algorithms before checkpoint. We put a restore hook into authDataImplementation to delay the decryption for the auth data at restore. This may be okay for auth data. However, if it is called after checkpint they may get an NoSuchFound algorithm exception. We are unsure if 128/256 decryption has been tested for checkpoint. We need to check that.

This says we need to check this, but I do not see it being addressed in the comment or the UFO.

I circled back on this with Tom W. I will update slide 22 with some actions he requested:

  1. Add to the existing instantOn password utilities tests to use the new AES-256 format (V1)
  2. Confirm the following: most likely com.ibm.websphere.crypto.PasswordUtil.passwordDecode(String) calls already fail before checkpoint because the JVM doesn't enable the algorithms before checkpoint

    Slide 28: Concern- The impact on Paris needs considering: Encrypted values in files and secrets are mounted into the Liberty pod as it starts. The Liberty instance that runs the customer's instance is not the same. The versions may not align and AES-128 may be used with the customer's instance but not supported by the Liberty instance. We need to ensure that the version of Liberty that runs the rest api feature is consistent for Paris.

I do not follow this. We are not removing support for AES-128 so if a customer has AES-128 encrypted passwords they would be correctly decrypted by Liberty. Perhaps there is impact on whatever Paris is where it would want to use AES-256, but that would just require Paris to update to a newer Liberty.

This is no longer a concern, I will remove it.

Question? Does the number of encypted passwords matter? Answer: No it doesn't matter. There is a one time cost.

This is not correct. It is a one time cost to generate the encryption key, but not to decrypt passwords. If you have 1 encrypted password it'll be faster than 100.

That is true. It is important to note the performance cost of decrypting the passwords is much less than the cost of deriving the AES key itself but there is still a cost. From a few tests locally, it is roughly 2 orders of magnitude less (x0.01). The actual decryption of each password took around 1ms or less. Whereas the AES key derivation took around ~400ms. This was from running on my laptop.

Zech-Hein commented 2 weeks ago

Thank you for your feedback @NottyCode! I have responded in my comment above

NottyCode commented 2 weeks ago

@Zech-Hein thanks

Zech-Hein commented 6 days ago

FAT test updates: https://github.com/OpenLiberty/open-liberty/pull/30259

Zech-Hein commented 13 hours ago

@OpenLiberty/demo-approvers Demo scheduled for EOI 24.24

UPDATE: Demo Completed - 11/26/2024