Closed dancristiancecoi closed 3 weeks ago
There are some failing integration tests that I will look into ASAP.
Attention: Patch coverage is 88.67925%
with 6 lines
in your changes missing coverage. Please review.
Project coverage is 65.40%. Comparing base (
a1e5db3
) to head (8e3b9cc
). Report is 11 commits behind head on main.
Integration tests were failing due to pre-set hashes in various internal_users.yml files used for integration tests having a different configuration to the default one (BCrypt.A with 4 log rounds vs BCrypt.Y with 12 log rounds). I've adapted the code so it verifies the passwords with a BCrypt configuration based on the hash.
@shikharj05
Thanks for the PR. Quick questions -
- How does this look like for end-users? Doesn't it break existing logins?
- Any performance numbers we can get to understand the difference?
I do not have any performance numbers but I can run some if required. What will be the best way to do it? Should I use the opensearch-benchmark tool locally or is there a github action we can run?
@shikharj05 I've ran the benchmarking tool with the percolator workload. It was against a one node local cluster running on my laptop so I am not sure how representative the results are :D.
For comparison I also attached a benchmark run in similar conditions but against the latest code in main.
testRunAgainstChanges.txt testRunAgainstMain.txt
Run 2:
testRunAgainstMain-run2.txt testRunAgainstMyChanges-run2.txt
To me it doesn't look like there is a significant variation either way in these bench-marking results.
This change LGTM! I am also looking at the benchmarking tool to look at ways to measure the impact on performance for the change in library.
There is a performance test suite that's in Draft and not unavailable yet unfortunately.
This change LGTM! I am also looking at the benchmarking tool to look at ways to measure the impact on performance for the change in library.
There is a performance test suite that's in Draft and not unavailable yet unfortunately.
Awesome, thanks @cwperks!
@shikharj05 I've ran the benchmarking tool with the percolator workload. It was against a one node local cluster running on my laptop so I am not sure how representative the results are :D.
For comparison I also attached a benchmark run in similar conditions but against the latest code in main.
testRunAgainstChanges.txt testRunAgainstMain.txt
Run 2:
testRunAgainstMain-run2.txt testRunAgainstMyChanges-run2.txt
To me it doesn't look like there is a significant variation either way in these bench-marking results.
Thanks, looked at the results, Run-1 shows some drop in throughput for index
, however in run-2 it matches up. LGTM for now!
The backport to 2.x
failed:
The process '/usr/bin/git' failed with exit code 128
To backport manually, run these commands in your terminal:
# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/security/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/security/backport-2.x
# Create a new branch
git switch --create backport/backport-4381-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 20c524ad994a9cc7d8757999f92f6d2fec6cb8ca
# Push it to GitHub
git push --set-upstream origin backport/backport-4381-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/security/backport-2.x
Then, create a pull request where the base
branch is 2.x
and the compare
/head
branch is backport/backport-4381-to-2.x
.
@dancristiancecoi could you please prepare a manual backport?
@dancristiancecoi could you please prepare a manual backport?
Sure! https://github.com/opensearch-project/security/pull/4428
Thanks everyone for the reviews!
Integration tests were failing due to pre-set hashes in various internal_users.yml files used for integration tests having a different configuration to the default one (BCrypt.A with 4 log rounds vs BCrypt.Y with 12 log rounds). I've adapted the code so it verifies the passwords with a BCrypt configuration based on the hash.
Hi @dancristiancecoi I'm not able to start a new cluster with old internal_users.yml
, is there documentations that I can take a look on fix this?
I got error:
Not yet initialized (you may need to run securityadmin)
Hi @ruanyl.
Are there any other errors in the logs to pinpoint to why the Security plugin was not initialised?
When you mention "old internal-users.yml file" is it similar to the ones used in the integration tests / demo config ? Anything that's unique about them?
There isn't documentation for this change as it SHOULD have worked seamlessly but it's very possible we've missed something
Hi @dancristiancecoi Thanks, I think I figured it out, just need to regenerate the password hash, then it works :)
I was using a internal_users.yml
that's generated before.
Description
This change removes the usages of Bouncy Castle's OpenBSDBCrypt from the code and replaces it with a FIPS compliant library that supports additional hashing algorithms like PBKDF2, Argon2 and SCrypt.
Furthermore it consolidates the password hashing and verification logic in one place.
This change will require a security review.
Issues Resolved
Related Issues
Testing
Various authentication attempts against a local 3.x deploy
Upgrade 2.11 -> 2.13 (with these changes back-ported)
Pre-upgrade:
Post-upgrade:
Extra:
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check here.