Need to create hash token using SHA-512 Algorithm, So on using _digest function of jmeter, I am getting a different token.
What is "salt"? is it same as secret key ?
How to use it?
${__digest(SHA-512,{test_test_test},SXF,,)}
See documentation of function:
https://jmeter.apache.org/usermanual/functions.html#__digest
Regarding SALT, it is described here:
https://en.m.wikipedia.org/wiki/Salt_(cryptography)
It’s not a private key, a salt is random data that is used as an additional input to a one-way function that "hashes" data, a password or passphrase. Salts are used to safeguard passwords in storage.
Related
How to invoke encryption API when we have multiple data to be encrypted at a single time? Suppose if we have 10 records and our requirement is to use encryption API only once. Then how it can be done?
Take a look at KMS API request body reference:
{
"plaintext": string,
"additionalAuthenticatedData": string,
"plaintextCrc32c": string,
"additionalAuthenticatedDataCrc32c": string
}
This API takes only one plain text value. You can concatenate multiple data, but they will be all made into one encrypted text, and will have to be decrypted all at the same time.
I have a situation where people consuming our API will need to do a partial update in my resource. I understand that the HTTP clearly specifies that this is a PATCH operation, even though people on our side are used to send a PUT request for this and that's how the legacy code is built.
For exemplification, imagine the simple following struct:
type Person struct {
Name string
Age int
Address string
}
On a POST request, I will provide a payload with all three values (Name, Age, Address) and validate them accordingly on my Golang backend. Simple.
On a PUT/PATCH request though, we know that, for instance, a name never changes. But say I would like to change the age, then I would simply send a JSON payload containing the new age:
PUT /person/1 {age:30}
Now to my real question:
What is the best practice to prevent name from being used/updated intentionally or unintentionally modified in case a consumer of our API send a JSON payload containing the name field?
Example:
PUT /person/1 {name:"New Name", age:35}
Possible solutions I thought of, but I don't actually like them, are:
On my validator method, I would either forcibly remove the unwanted field name OR respond with an error message saying that name is not allowed.
Create a DTO object/struct that would be pretty much an extension of my Person struct and then unmarshall my JSON payload into it, for instance
type PersonPut struct {
Age int
Address string
}
In my opinion this would add needless extra code and logic to abstract the problem, however I don't see any other elegant solution.
I honestly don't like those two approaches and I would like to know if you guys faced the same problem and how you solved it.
Thanks!
The first solution your brought is a good one. Some well known frameworks use to implement similar logic.
As an example, latests Rails versions come with a built in solution to prevent users to add extra data in the request, causing the server to update wrong fields in database. It is a kind of whitelist implemented by ActionController::Parameters class.
Let's suppose we have a controller class as bellow. For purpose of this explanation, it contains two update actions. But you won't see it in real code.
class PeopleController < ActionController::Base
# 1st version - Unsafe, it will rise an exception. Don't do it
def update
person = current_account.people.find(params[:id])
person.update!(params[:person])
redirect_to person
end
# 2nd version - Updates only permitted parameters
def update
person = current_account.people.find(params[:id])
person.update!(person_params) # call to person_params method
redirect_to person
end
private
def person_params
params.require(:person).permit(:name, :age)
end
end
Since the second version allows only permitted values, it'll block the user to change the payload and send a JSON containing a new password value:
{ name: "acme", age: 25, password: 'account-hacked' }
For more details, see Rails docs: Action Controller Overview and ActionController::Parameters
If the name cannot be written it is not valid to provide it for any update request. I would reject the request if the name was present. If I wanted to be more lenient, I might consider only rejecting the request if name is different from the current name.
I would not silently ignore a name which was different from the current name.
This can be solved by decoding the JSON body into a map[string]json.RawMessage first. The json.RawMessage type is useful for delaying the actual decoding. Afterwards, a whitelist can be applied on the map[string]json.RawMessage map, ignoring unwanted properties and only decoding the json.RawMessages of the properties we want to keep.
The process of decoding the whitelisted JSON body into a struct can be automated using the reflect package; an example implementation can be found here.
I am not proficient on Golang but I believe a good strategy would be converting your name field to be a read-only field.
For instance, in a strictly object-oriented language as Java/.NET/C++ you can just provide a Getter but not a Setter.
Maybe there is some accessor configuration for Golang just like Ruby has....
If it is read-only then it shouldn't bother with receiving a spare value, it should just ignore it. But again, not sure if Golang supports it.
I think the clean way is to put this logic inside the PATCH handler. There should be some logic that would update only the fields that you want. Is easier if you unpack into a map[string]string and only iterate over the fields that you want to update. Additionally you could decode the json into a map, delete all the fields that you don't want to be updated, re-encode in json and then decode into your struct.
I have followed this article on how to implement password hashing and salting
http://www.codeproject.com/Articles/608860/A-Beginners-Tutorial-for-Understanding-and-Impleme
I have implemented all the code mentioned in the article into my MVC 5 web application, however, whenever I store the PasswordHash and Salt, both of these strings save in my User table as question marks, e.g, ????????????????
The database I'm using is Sql Server 2008 R2. The two fields within my database User table have both got a datatype of Nvarchar(100)
I should also mention the data is being persisted to the database using Entity Framework 5.
Has anyone seen this before? I'm thinking it might be a datatype problem, i.e., shouldn't be Nvarchar, however, I don't really know.
Any help with this would be great.
Thanks.
There's a problem in Utility.cs:
public static string GetString(byte[] bytes)
{
char[] chars = new char[bytes.Length / sizeof(char)];
System.Buffer.BlockCopy(bytes, 0, chars, 0, bytes.Length);
return new string(chars);
}
The function is fed random bytes. This is not how you create a random string. Characters are not meant to store binary data. Such strings will be hard to swallow for many components.
Use Convert.ToBase64String and don't trust random articles on the web. Validate what you find with your own understanding before using it.
SHA256 are not string, are byte arrays. Use byte[] in your client code, use VARBINARY on the server code.
I am working with a pet project and I come to a point where I want to add user sign up support. After some research I decide to go with saving hashed password and salt in my database and never the original password. However I am confused to what the steps are and in what order. Below is my assumption:
Signup
Client sends username and password to server (https)
Server grabs the password, generates a random salt
Base64 encode the salt
Hash the password with the stringify salt
Base64 encode the password
Save the password and salt into database
Login
Client sends username and password to server (https)
Server grabs username and password, look up hashed psw and salt from database
Hash password using the salt, base64 encode the result
Compare the password with hashed psw in database
If match, authenticate user
I am implementing my system as my assumption, and everything seems to work. However I am not sure about the base64 encoding part. What is the purpose of encoding the password and salt from binary to string, and can I skip this step? And if my assumed process is wrong, what are the correct steps?
P.S I am using express.js as the server, mysql as the database
The general idea is OK, but I've got some remarks:
Instead of using a hash, you should use a PBKDF, a Password Based Key Derivation Function. It is best to use a standardized version, that would be PBKDF2. Together with the salt, you should also choose a number of iterations to thwart attacks.
Make sure you always use the same character-encoding for the username and password.
The cryptographic algorithms should be based on binary input and output.
At the time you store or load binary data to a text presentation, you should use Base 64 encoding / decoding respectively.
So the scheme contains the following issues:
Using a hash instead of a PBKDF.
Using a base 64 encoded salt as input for the hash.
You need to understand what salts means. Its a way just to throw obstacles against possible brute force attack using rainbow table. Which means some bad guy will try with high computing power all possible hashes that can be generated. Then try to extract the plain text out of such hash.
Thus the salt is there to make sure even with such attack the returned plain text is not the correct one.
For example:
username: "Xavier_Ex"
password: "Ilovestackoverflow"
Such password will be hashed to "sfhj87s&^f". Now rainbow table can also say
"sfhj87s&^f" -> Ilovestackoverflow... bleh, your password is cracked.
But when salted it will be like "Ilovestackoverflow" -> "Io*ves5tacmkove3rflow".
when this is hashed "Io*ves5tacmkove3rflow" -> "dfgdfgdf"
With rainbow table that "dfgdfgdf" will return "Io*ves5tacmkove3rflow" .. your password is still secret.
In short.. you can skip this unless you do do need such protection.
I'm defining my custom model for pas.plugin.sqlalchemy.
Existing table of login details have binary field as password column. how should be define in model as binary. I tried to import _Binary class from SQLAlchemy after Googling but it doesn't import. Firstly I tried LargeBinary but when table been created its takes field type as Image which I dont want.
Any help would be appreciated.
Regards,
WEBBYFOX
I'm not surprised that _Binary doesn't work - even if it did, it's generally a very bad idea to use something that's intended as a private class. But "sqlalchemy.Binary" is a perfectly acceptable type.
That said, I doubt anybody's tested pas.plugins.sqlalchemy with Binary data for the password: PAS is a way to drop-in replacements for the existing Plone system, and out-of-the-box, Plone expects passwords to be strings.