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 ...
Related
It might be a bit out of scope for JWT concept but how can i ensure the confidentiality of input parameters in order to generate token?
I have three parameters. Client IP Address, username and password. IP addresses could be spoofed. Usernames and passwords might be stolen. Due to all these reasons I doubt of the security of input parameters.
To ensure higher level security i might be considering asymetric encyrption. So, do you think that it would be a good aproach to accept only encrypted username and password with private key?
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.
I need to salt a hashed(SHA-256) password using Apache Shiro. I used the following method, but it uses plainText password as a parameter. But I need to get an alredy hashed password from the frontend and salt it and store in the server side. Otherwise if I use the following method I will have to pass the plain password all the way through frontend, which is not secure. So please suggest me a way to overcome this problem.
String hashedPassword = new Sha256Hash(plainTextPassword, salt);
You cannot salt the password after it has been hashed. Salting works by combining the salt with the plain text password, and hashing the entire thing. This is why Shiro's Sha256Hash requires you to give it the plain text password.
It is common to pass the plain text password from the front end to the service layer as long as this communication is secure (e.g. HTTPS for web UIs). The only thing you should not do is store the plain text password in a database (which a correctly configured Shiro will not do) because your database may be compromised.
When passing the plain text password from the front end to your service, it will only exist in memory for a short time before being garbage collected. To obtain the password someone would have to either break your SSL connection (in which case you are screwed anyway) or compromise your server and dump the memory (in which case you are screwed anyway).
In case of claim based authentication which uses SSO, an application receives a token from the issuer for a particular user and that token contains the claims as well as some sort of digital signature in order to be traced by the application that an issuer is a trusted one.
I want to know, if there are some sort of algorithms involved by which this application recognizes an issuer?
I had read that issuer has a public key and all the other applications have their own private key, is it true?
There are many protocols, formats and methods of doing Single Sign On such as Security Assertion Markup Language (SAML), OpenID and OAuth. The goal is for one entity, such as a website, to identity and authenticate the user (such as through a user name and password) and other entities, such as other websties, trust the evidence of that authentication through a token. This means users need not remember yet another password and each website maintain their own list of passwords.
This trust is usually enforced through cryptography using a digital signature. Digital signatures are used because it allows the trusting entity to verify token was (1) issued by the authenticating entity only and (2) not tampered with without being able to impersonate (pretend to be) the authenticating entity.
As you say above, this is performed using asymmetric or public key cryptography. Symmetric cryptography, such as the AES or DES algorithms, use a single key to encrypt and decrypt data. Asymmetric cryptography, such as the RSA algorithm, uses two related keys. Data encrypted using one can only be decrypted by the other and vice versa.
One key is usually kept secret, called the private key, and the other is distributed widely, called the public key. In the example above, the authenticating entity has the private key that allows it to encrypt data that anyone with the public key can decrypt.
It would seem to follow that the authenticating entity would just encrypt the user details and use that as the token. However, commonly used asymmetric algorithms like RSA are very slow and encrypting even small amounts of data can take too long.
Therefore, instead of encrypting the user details, the authenticating entity generates a "hash" or "digest" and encrypts that. A hash algorithm converts a piece of data into a small number (the hash) in a very difficult to reverse way. Difference pieces of data also create different hashes. Common hash algorithms include Message Digest 5 (MD5) and Secure Hash Algorithm (SHA) and its derivatives like SHA1, SHA256 and SHA512.
The hash encrypted with the authenticating entity's private key is called a digital signature. When it receives the token, the trusting entity decrypts the token using the authenticating entity's public key and compares it to a hash it calculates itself. If the hashes are the same, the trusting entity knows it has not been modified (because the hashes match) and it must have come from the authenticating entity (because only it knows its private key).
If you want more information about SAML and claims-based authentication, I found this video very helpful. It does get complicated rather quickly and you may need to watch it multiple times but Vittorio covers most of these concepts in great detail.
I'm storing the user's credentials in a database with the encoded password: sha1(pw + salt) and the salt.
When I'm trying to login the user from a client app I do the same thing only with a different salt value, so I send the sha1(pw + another_salt) and another_salt for authorization.
The question is that what further modification should be done to the received encoded password to be able to check against the stored value.
If you send something from client it doesn't matter if it's hashed password or just string. And if it's content generated by client (i.e. you generate salt on client, not on server) - attacker could as well just send your string. So if it's not secured connection, then you add additional work which doesn't help.
To allow checking passwords on server with another salt, you need to store original password in clear text.
That's the whole point of storing hashes instead of passwords in database is to not allow guessing them from hash only. And if you salt them additionally, then you need to use the same salt (it's public, as it's stored in database in clear text, but it's now part of original password). What you ask is something like this:
Haw to login on user (whose password is "secure password" + "hard" => sha1("secure passwordhard")) sending something + "soft" (and then test with sha1(something + "soft")) instead.
If you really need this app to work, just send user's password in cleartext from client app, but over secured connection.