When I'm creating an at_hash of an access token, should the hash be salted or not? If yes, how can it then be validated if the client does not know the salt that was used? The specs does not say much about it, unfortunately.
No, the hash should not be salted. Remember that the at_hash binds the access_token to the id_token and protects it since the id_token is signed. The value of an access_token is quite different from a password where a salt is needed because it has less characters and is less random.
Related
The CredentialRepresentation used in the Keycloak 'reset-password' REST API contains fields for hashing algorithm, hashed password, hashing iterations etc.
This implicates that I can pass through a hashed password and all its hashing specifications, instead of passing the plain-text password to the service. This is exactly what I'd like to do, because passing a plain-text password doesn't feel right.
When I try to call the service without the plain-text value however, I get a 400 error with the error message that the plain-text value is missing. Is there any way to pass just the hashed password?
Passing in a plaintext password (via HTTPS of course) allows keycloak to hash it using the hash algorithm policy of the realm.
If you want to pass in the hashed password value, iterations and algorithm then you also need to provide the hashing SPI that implements PasswordHashProviderFactory and PasswordHashProvider. And I don't think this is available via the reset-password API, but would work with the Update User API (I haven't tested this).
Rather than specifying a new password manually a better security practice is to use the PUT /admin/realms/{realm}/users/{id}/execute-actions-email admin call with "UPDATE_PASSWORD" as the required action. This causes Keycloak to send an email to the user that gives a link to set a new password directly.
If I have two JWTs, where their set of claims and headers are the same but the order they are stored in json is different, should they be considered equal?
Clarification:
I am aware that as a user of JWTs you should not need to compare them, but that is not what I am doing.
Say we have some jwt library, and you have some object that represents a JWT in it's decoded form. If we create an encoded JWT from our decoded JWT and then apply it to some function that returns once again the decoded JWT. Do we consider the two decoded JWTs to be equal if the order in which the claims or headers are stored in some collection has changed due to the decoding process?
Thinking more about this, perhaps it is wrong to store the headers and claims in a collection which has some notion of order? Using something like a set makes this problem disappear?
Depends on what you mean by 'different'. If the claims are the same then they are the same in the sense that the information transferred is equal. But if they both have the same signature then at least one will be invalid.
Also you shouldn't need to compare JWT claims at all. If you're storing the token and comparing the token given then you should revisit why you're using JWT over something like session.
JWT is designed to be independent. Because JWT tokens are claims based authentication the validation is done against the signature, not against anything on the server.
I'm making a forget password feature in my web app, problem is I store user's password using:
Hash::make('_their_password_')
Is there any way to re-hash it back or any recommended approach for this?
The point of hashing a password is that it's (supposed to be) an irreversible operation. If your database is compromised, the attacker will gain access to the hashes, but not to the passwords. That way the attacker can't log in with the users' passwords on other sites.
Make a "we'll reset your password" feature instead of a "we'll send you your password" feature.
Note that there are also other best practices you absolutely should be following regarding password hashing, to make sure the "supposed to be" above actually holds, and to further minimize the impact if your site is compromised. Laravel's Hash class seems to already be using the password-appropriate hash function Bcrypt. However, make sure you're using a salt when you're hashing your password.
The Laravel's Hash method cannot be reversed.
One way encryption is the best way to store user passwords, or other sensitive data.
One way means that your data can be converted into an encrypted string, but due to a complex algorithm with painful maths, reversing the process is not possible. This makes storing passwords a doddle! Your customers don't have to worry about you knowing their passwords, but you are still able to compare them (by hashing the password they provide) or change the password if needed.
If you need to reverse, you can use Crypter class.
$secret = Crypter::encrypt('I actually like Hello Kitty');
$decrypted_secret = Crypter::decrypt($secret);
Read more about encryption here http://codehappy.daylerees.com/encryption
If you want to verify the content of password with other value use the following.
return Hash::check($value, auth()->user()->password);
If I use RSA authentication for my web app would I still need to take care of CSRF attacks by using tokens or RSA authentication will take care of it.
that depends on your implementation ... rsa itself has nothing to do with csrf ...
an authentication schema can provide some protection (for example if you let the user sign all of it's inputs), but honestly: what's the deal with protecting user inputs from csrf?
on the server side, on login create a salt stored within the users session, calculate hash(current_timestamp, salt) everytime you need to protect a user input, and give that value + the current_timestamp as hidden field to the form ... when you receive the user input, get the salt, and recalculate the value ... if that one matches with what you got from the client, it is unlikely that the input came through csrf ...
since you never expose the salt to the user, there is no way (except taking it directly from your session database which means a compromised system) for the user or an attacker to obtain that salt ...
I have MD5 hashes of passwords in a database that I want to use against HTTP AUTH DIGEST. But in reading the docs, it looks like the digest hash contains a hash of the username,realm and plaintext password. Is there any way to use the MD5 hash of the password in this situation?
No. If the hash they need is generated like so:
MD5(username + realm + password)
You are out of luck.
If they are hashing the password like so:
MD5(MD5(password) + username + realm)
You'd be able to do that with just the hashed password. But it doesn't sound like that's what's going on.
No, you have to store in the tables the HA1 hash of Digest and use that for other types of auth (forms and Basic). See here: Storing password in tables and Digest authentication
No, this is not possible. The whole point of digest authentication is to avoid replay attacks, i.e. were somebody has only a hashed version (of some authentication data) rather than the real data.
Not only is it a hash of username, real, and plaintext password, but also a nonce, which will change every time. So you really need the plaintext password.
No. In digest authentication, the password is hashed with a challenge, there is no way to make it work with another hash.
Basic auth over HTTPS is more secure and it should work with your hashed password.