Migrating from Spring Security 5.x Bcrypt hashes to Quarkus - bcrypt

I'm attempting to rewrite an application that was originally developed with Spring. The user authentication is provided via Spring Security that uses Bcrypt to generate and check hashed passwords.
They are stored in the database in the format shown below. As far as I can tell, this is how it is represented:
| |RR| Salt | Hashed Password |
$2a$10$Dh23I3CO6l1n3mOofdazreNLg2OHxzDrxyGGZEstTbITKs.cX3N/u
(Where RR is the number of rounds)
I've tried migrating this to a new table structure as show in "Table 3. Example Table" under Using a Hashed Password Representation of 4.6. Component Documentation, for example:
NAME | PASSWORD | SALT |ITERATION_COUNT|
=====|=================================|========================|===============|
test | NLg2OHxzDrxyGGZEstTbITKs.cX3N/u | Dh23I3CO6l1n3mOofdazre | 10 |
I have configured the mapper in application.properties as below:
quarkus.security.jdbc.principal-query.sql=SELECT u.password, u.salt, u.iteration_count FROM test_user u WHERE u.name=?
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.enabled=true
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.password-index=1
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.hash-encoding=base64
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.salt-index=2
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.salt-encoding=base64
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.iteration-count-index=3
However, I either get an error caused by invalid base64 characters (which isn't a total surprise as the implementation in Spring Security states it's not a MIME compatible base64 implementation) or, when that error is not present, it fails to verify the password.
How would I be able to migrate all the users to the Bcrypt implementation that Quarkus uses?

So I didn't need to split up the salt, hash and iteration count at all. You can continue to use the current 'single string' format. The trick is to configure the mapper as follows (note the -1 for the salt and iteration-count properties):
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.enabled=true
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.password-index=1
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.salt-index=-1
quarkus.security.jdbc.principal-query.bcrypt-password-mapper.iteration-count-index=-1
Although I don't see it mentioned in the Wildfly Elytron docs, or in the Quarkus configuration documentation, it is clearly handled (see PasswordKeyMapper.java on GitHub)
The logic caters for when these two properties are set to -1. It then parses the full string and verifies the password successfully.

Related

ConstraintViolationException - extract field name which caused exception

I'm using hibernate-validator with a JAX-RS service to validate query parameters using #NotNull:
#GET
public Response doSomething(#NotNull #QueryParam("myParam") String myParam) {...}
This works as expected and throws a ConstraintViolationException if myParam is null. I'd like to extract the param name which is associated to the violation (e.g. myParam), and return that in the response message to the client but there does not appear to be an obvious way of extracting this from the exception. Can someone provide some insight?
As of BeanValidation 1.1 there is a ParameterNameProvider contract which makes parameter name extraction configurable. As mentioned in the other answer, with Java 8 you can get the parameter names in the byte code provided you compile with the -parameters flag. Use the ReflectionParameterNameProvider in this case. However, even with Java 7 you can get parameter names, for example by using the ParanamerParameterNameProvider. This parameter name provider is based on Paranamer and there are several ways to set it up.
This only works if you're using Java 8, as prior to Java 8 the actual parameter name was lost at compile time. Its now retained, assuming you compile and run at Java 8. See also http://docs.jboss.org/hibernate/validator/5.2/reference/en-US/html_single/#_java_8_support

How to generate hash(SHA1) using beanshell in JMeter?

How do I want to generate a hash using beanshell(SHA1) in JMeter to sign up to a application?
I'm not able to get a substantial answer yet from net
Generating a hash is pretty easy, just use DigestUtils class from Apache Commons Codec library (it's a part of JMeter so you won't need to install anything external)
Something like:
import org.apache.commons.codec.digest.DigestUtils;
String foo = "bar";
String sha1Hex = DigestUtils.sha1Hex(foo);
Usually SHA1 is being required for signing requests to OAuth-protected applications, if it is your case, I believe How to Run Performance Tests on OAuth Secured Apps with JMeter will be extremely helpful.
There's a new JMeter function __digest, currently in nightly builds which can be used to encode strings
In your case to save in sha1Value variable the result of myVar variable use the following:
${__digest(SHA-1,${myVar},,,sha1Value)}
4th parameter is uppercase, so you can send true to automatically uppercase it.

REST API test cucumber steps best practice

Trying to write up cucumber feature steps for REST API test.
I am not sure which approach is better:
Given I log in with username and password
When I add one "tv" into my cart
And I check my cart
Then I should see the item "tv" is in my cart
or
Given the client authenticate with username and password
When the client send POST to "/cart/add" with body "{item: body}"
Then the response code should be "200"
And the response body should expect "{success: true}"
When the client send GET to "/cart"
Then the response code should be "200"
And the response body should expect "{"items": ["tv"]}"
Is there any convention to follow when people trying to write cucumber steps for REST API?
I just stumbled on this helpful article: https://www.gregbeech.com/2014/01/19/effective-api-testing-with-cucumber/
To summarize...
Scenario: List fruit
Given the system knows about the following fruit:
| name | color |
| banana | yellow |
| strawberry | red |
When the client requests a list of fruit
Then the response is a list containing 2 fruits
And one fruit has the following attributes:
| attribute | type | value |
| name | String | banana |
| color | String | yellow |
And one fruit has the following attributes:
| attribute | type | value |
| name | String | strawberry |
| color | String | red |
Validating a result against JSON is tricky business because if the result is an array, the elements may not be the same order as how you are validating in the test.
Edit: Updated link using finderAUT's comment. Thanks!
Here's a (close enough) example to what the Pragmatic Programmer's "the Cucumber Book" says about testing REST APIs via Cuke,and it seems to more closely relate to your second example:
Feature: Addresses
In order to complete the information on the place
I need an address
Scenario: Addresses
Given the system knows about the following addresses:
[INSERT TABLE HERE or GRAB FROM DATABASE]
When client requests GET /addresses
Then the response should be JSON:
"""
[
{"venue": "foo", "address": "bar"},
{ more stuff }
]
"""
STEP DEFINITION:
Given(/^the system knows about the following addresses:$/) do |addresses|
# table is a Cucumber::Ast::Table
File.open('addresses.json', 'w') do |io|
io.write(addresses.hashes.to_json)
end
end
When(/^client requests GET (.*)$/) do |path|
#last_response = HTTParty.get('local host url goes here' + path)
end
Then /^the response should be JSON:$/ do |json|
JSON.parse(#last_response.body).should == JSON.parse(json)
end
ENV File:
require File.join(File.dirname(__FILE__), '..', '..', 'address_app')
require 'rack/test'
require 'json'
require 'sinatra'
require 'cucumber'
require 'httparty'
require 'childprocess'
require 'timeout'
server = ChildProcess.build("rackup", "--port", "9000")
server.start
Timeout.timeout(3) do
loop do
begin
HTTParty.get('local host here')
break
rescue Errno::ECONNREFUSED => try_again
sleep 0.1
end
end
end
at_exit do
server.stop
end
I've been using cucumber to test and more importantly to document the API that I created using rails-api in my current project. I looked around for some tools to use and I ended up using a combination of cucumber-api-steps and json_spec. It worked well for me.
There is no convention on how to write the cucumber steps. The way you write your steps depends on how you want to use your cucumber suite. I used the cucumber output as the reference for our Angular JS client devs to implement the API client. So my cucumber steps contained the actual JSON requests and responses along with the status code for each scenario. This made it really easy to communicate with a client side team whenever something changed ( especially when the client side team was not physically present at my workplace ).
Everytime I would create or update an API, the CI server would run cucumber as part of the build and move the HTML formatted output to a "build_artifacts" location that can be opened in the browser. The client side devs would always get the most recent reference that way.
I've written all of this down in a blog post about creating a tested, documented and versioned JSON API, hope it helps you in some way.
One of Cucumber's original intents, which contributes to its design, is to bridge the gap between technical implementation, and people who know the business needs, so that the test descriptions could be written and/or understood by non-developers. As such, it's not a great fit to detailed technical specs, or blow-by-blow unit testing.
So that would point me to your first test description, if that's also the reason you are using Cucumber.
There is no major problem with implementing tests like the second version, Cucumber can support it. There probably are not a large number of statement types you would need to parse either. But you could end up fighting the test framework a little, or going against your rationale for using Cucumber in the first place.
As for a convention, I am not aware of enough REST API tests in practice to comment, and none that I have seen tested have used Cucumber as the framework.
Update: Browsing around SO on the subject, I did find a link to this: https://github.com/jayzes/cucumber-api-steps which is more similar to your second format.
There are a few libraries now for server side REST testing with cucumber in Ruby. Here's a couple:
Cucumber-API-Steps. (Recommended)
Cucumber-API. A small tutorial for that is here.
The library I've been using for server side REST testing with cucumber is Cucumber-API-Steps.
Cucumber-API-Steps
Here's how I'd write your test using 'cucumber-api-steps' (Recommended):
#success
Scenario: Successfully add to cart
Given I am logged in
When I send a POST request to “/cart/add” with the following:
| item | body |
Then the response status should be “200”
And the JSON response should have "success" with the text "true"
When I send a GET request to “/cart”
Then the response status should be “200”
And the JSON response should be "{'items': ['tv']}"
And here's what my tests look like using 'cucumber-api-steps':
#success
Scenario: Successfully log in
Given I am logged out
When I send a POST request to “/login” with:
| username | katie#gmail.com |
| password | mypassword |
Then the response status should be “200”
And the JSON response should have "firstName" with the text "Katie"
Cucumber-API
Here's how I'd write your test using 'cucumber-api':
#success
Scenario: Successfully add to cart
Given I am logged in
When I send a POST request to “/cart/add”
And I set JSON request body to '{item: body}'
Then the response status should be “200”
And the response should have key “success” with value “true”
When I send a GET request to “/cart”
Then the response status should be “200”
And the response should follow "{'items': ['tv']}"
And here's what my tests look like using 'cucumber-api':
#success
Scenario: Successfully log in
Given I am logged out
When I send a POST request to “/login” with:
| username | katie#gmail.com |
| password | mypassword |
Then the response status should be “200”
And the response should have key “firstName”
Note about Cucumber-API: There is no way currently to do should have key “firstName” with value “Katie”. The "with value" part has not been done yet.
Also "Follow" expects a JSON file
Another resource is here, but it is old (2011).
I would recommend your first scenario.
From my own experiences I personally feel that the biggest value you get from using BDD as a software delivery method, is when you place the emphasis on business value.
In other words the scenarios should be examples of what behaviour the business wants, rather than technical implementation. This ensures that the development is driven by the goals of the business and the deliverables match their expectations.
This is known as outside-in development.
Additional tests of the system behaviour can and should be used to cover the technical requirements but I think there's less value in spending effort writing these up in natural language, which is often time consuming and laborious across a large number of scenarios.
I recommend the following approach:
1) Work with the BAs and POs to develop examples of the behaviour they want using non-implementation specific language (like your first example).
2) Engineers use these to drive the development from a test first approach, automating them as integration tests - with the majority below the browser (against your REST API for example) and the most core scenarios also through the browser(if you are developing one).
3) Engineers TDD the feature code with unit tests until both the unit tests and BDD examples pass.
I think the first one is better. I would put the technical in the ruby classes and modules. E.g like module cart.add(items) in the when step and in the then step put expect(cart.item).to include('items' => a_string_matching(item))
By this, the ruby classes and modules can be reuse in another features steps. E.g like maybe you have another scenario which would add multiple items into the cart then validate the total amount.
However, the second 1 I think can make it like technical features. E.g like common/global header or body request is expected across all the api.
See here: https://github.com/ctco/cukes-rest. It provides a Cucumber DSL to test RESTful APIs.

Verifying signature of non-hashed data with Ruby OpenSSL

I have an RSA public key, some data and a signature of that data. I need to verify the signature. However, the signature is not of a digest of the data, but of the entire data. (The data itself is only 16 bytes, so the signer doesn't bother to hash the data before signing it.) I can verify the signature in C by specifying a NULL engine when initializing the context:
EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new(verify_key, NULL);
However, I have been unable to find an equivalent in Ruby's OpenSSL::PKey::PKey verify method. That method requires a Digest object, and there is no Digest that I can find that doesn't actually hash but just returns the data as-is. I tried creating my own Digest subclass, but I don't believe that can work, since the underlying OpenSSL library won't know about the existence of a custom digest type.
Am I stuck, or is there a way to solve this problem given that I cannot modify the code run by the signer?
Summarizing the answer from the comments in order to remove this question from the "Unanswered" filter...
owlstead:
Have you tried to find a function like public_decrypt? It may work, as normally you should not encryption with a private key and decrypt with a public key. With a bit of luck it will accept the signature version of PKCS#1 padding (note that the padding used for encryption and signing is different in PKCS#1).
Wammer:
Of course - decrypting the signature with the public key and verifying that it matches the data works fine. So far this is working fine with the standard PKCS#1 padding, but I'll do some more research to see if the differing encryption and signing paddings are a problem in practice. Thanks.
owlstead:
After a decrypt and validation of the padding, all that is left is a (if possible, secure) compare. So that would replace the verification function pretty well. Most of the security is in the modular arithmetic and padding.

What is the safest way to store a password using Code Igniter?

I am using Code Igniter for my current project.
As of now, I am using MD5 for password hashing, but I have read at a lot of places, that it is not a good practice to do so.
What should I go with?
Using a salt
Or should I use bcrypt
Also, if bcrypt is recommended, then how to use it with Code Igniter?
EDIT
I have put these files in application/libraries
PasswordHash.php
c/Makefile
c/crypt_private.c
In my controller, I am using this code -
$params = array(
'phpass_hash_strength' => 8,
'phpass_hash_portable' => FALSE
);
$this->load->library('PasswordHash', $params);
$password = $this->passwordhash->HashPassword($pwd);
I am getting these errors -
A PHP Error was encountered
Severity: Notice
Message: Uninitialized string offset: 3
Filename: libraries/PasswordHash.php
Line Number: 116
A PHP Error was encountered
Severity: Warning
Message: strpos() [function.strpos]: Empty delimiter
Filename: libraries/PasswordHash.php
Line Number: 116
Update
Removed PasswordHash.php, using SimpleLoginSecure now.
Use bcrypt. This discussion came up here in the comments to my answer. You can use a library such as phppass to really simplify the password encryption.
On the matter of salt. Use it! Otherwise somebody can simply go to this site and download the rainbow tables that will cover the large majority of passwords the average users chooses. Especially with all the security leaks in the last few months, now is not the time to be saying you won't use something as simple to implement as random salt.
UPDATE
To use PHPPass with CI, download and extract the files from the phppass website, linked above. Put the PasswordHash.php file into your CI application/libraries directory.
In your code, you then load the library via: $this->load->library('PasswordHash',array(8, FALSE));
Hashing passwords is then as simple as $this->PasswordHash->HashPassword($password);
To later check if a password is correct, it is as simple as:
$password = $_POST['password'];
$actualPassword = /*Get the hashed password from your db*/;
$check = $this->PasswordHash->CheckPassword($password, $actualPassword);
I've taken this demo from http://dev.myunv.com/articles/secure-passwords-with-phpass/ which gives you a lot more informations. I've modified that tutorial slightly to utilize CI's loader which is why you don't need the include or new statements.
why use md5() when it is just as easy to use sha1() ?
Also salting the passwords is always a good idea as it effectively removes the threat of a Rainbow Table attack
In my experience a salted SHA1 hash is pleanty secure for 99% of web application situations.
Code Igniter has changed since the time this question was asked. But for the benefit of some who may not have come across the extensive documentation of CI or haven't seen this before, CI has an encryption class which provides a two-way data encryption using the Mcrypt library of PHP.
After initializing the class using:
$this->load->library('encrypt');
You can encrypt as follows:
$msg = 'My secret message';
$encrypted_string = $this->encrypt->encode($msg);
and decrypt as follows:
$encrypted_string = 'APANtByIGI1BpVXZTJgcsAG8GZl8pdwwa84';
$plaintext_string = $this->encrypt->decode($encrypted_string);
CI also has a non-decodable 1-way hashing:
$hash = $this->encrypt->sha1('Some string');
For more information see:
http://www.codeigniter.com/user_guide/libraries/encryption.html

Resources