Sorry, It may be posible few things are repeated in my question.
I have gone through some documentation/discussion signing an API request and twitter signature documentation
As per the discussion here signing an API request With a signed request the password is kept safe and an attacker cannot use the information in the query to sign another request.
But for signature generation uses SHA-1 non reverting hash function.
My Question is:-
If signature used to authorizes /authenticate client request, how that signature used on server side to check and validate the user request?
Related
Most of the time we are using JWT access token validation to make sure that the request to e.g. an API is secure. However do we need to make sure that the response that comes back from that system (or API) is secure enough? Do we need to be worry? and how should we mitigate it?
appreciate all kind of advice.
As usually with those things, the answer is it depends ;)
Who is the owner of the API that you're calling? If you're calling your own API then you can be pretty sure about the validity and safeness of the response. If you're calling a third-party API then you might add some checks. Maybe scan files for malicious code if you're downloading any files from that API? Or check whether the response is not trying to inject any code, etc. It might not be the easiest thing to do, though.
Are you using a secure connection to the API? If you use SSL then you're sure that no one has tampered with the response. Additionally you can verify certificate chains to verify that you're connecting to the right API endpoint and not to a malicious one. If you're not using SSL then you might want to verify the response from the API, whether it's been tampered or not. How to do that verification again might not be trivial, but maybe the response can be signed?
Where is the client which is talking to the API? If you have a backend client talking to an API then you should not worry that response might be altered at client side. If you have an SPA running in a browser, then the response might be altered by a man-in-the-browser attack. Such response can be altered even if you use SSL to connect to the API, as SSL is terminated in the browser and a compromised user-agent will grant the attacker access to the decrypted API response. You can also have an XSS attack which alters responses in your app. Again, to protect from that threat you would need responses to be signed, or have another way of verifying integrity.
One way of verifying integrity of a response is to use signed JWTs with asymmetric signing. The API can sign the response with its private key, and then you can verify whether it's not been tampered with. E.g. the JARM spec uses that for OAuth flow responses.
Hopefully I can make this clear enough.
Goal:
Client Certificate-Authenticated Azure Function
Scenario:
Azure Function App with:
HTTPS Only: set to Yes
Client certificate mode: set to Require
HTTP-triggered Azure Function (Python) which:
Loads client certificate from X-ARR-ClientCert header
Pulls a pre-shared client cert from a database and compares:
Issuer
CommonName
Not Valid Before/After
Hits the listed OCSP endpoint to see if cert is revoked
If properties from each cert match and the certificate has not been revoked, the Function will generate a SAS token for the requestor and send it in the response.
Question:
How is the cryptographic part of client cert auth handled in this scenario?
According to this (great) blog post, there is a CertificateVerify step where...
"The client is authenticated by using its private key to sign a
hash of all the messages up to this point. The recipient verifies
the signature using the public key of the signer, thus ensuring it
was signed with the client’s private key."
I don't see a way to access ...all the messages up to this point. to validate this has occured using the Function (Python) code.
Is this something Microsoft handles automagically (similar to how they forward client certs via the X-ARR-ClientCert header)? Or is this not possible?
From what I implemented in a similar case:
Your app received the certificate via the header and must:
load the certificate (using the library cryptography in python for example)
verify the signature of the certificate with you certificate authority
verify the date of validity
verify that it has not been revoked
Using web app (but the same would apply to functions), the Azure frontend seems to just launch authentication protocol to verify that the client that send the certificate has the private key associated (and launch the mutual auth protocol as described in the blog post). But it does not verify the validity or signature of the certificate.
The CertificateVerify step you're mentionning seems to be handled by the Azure Frontend, I don't think your need to worry about this process.
Hopes this helps !
I have been reading about JWT and I understand it has three parts namely, header, payload and signature.
I keep the hashing algorithm used in headers, basic information in a payload eg. name, age , role, expiry etc in payload and then both of these are base64 encoded and then hashed using the
algorithm specified in headers to obtain the JWT
I have a frontend where I can login using username and password.
The login request goes to a server which authenticates it and returns a JWT. Lets suppose the algo used is HS256 which is a symmetric key algorithm.
So the server will have the secret key using which the JWT will be generated.
As part fo login request's response, the browser will have the JWT.
Now this JWT could be tampered with on the way so before it is used, I should verify the authenticity of JWT.
To verify, I need the secret key.
Questions:
How do I get this secret key on the frontend?
The payload can keep any information about a user (Not any sensitive information eg. passwords). Since JWT can be tampered with on the way, is it not dangerous to use the payload information without verifying the JWT on frontend?
The server which receives the JWT is the one who verifies the token. If someone modified the token, verification will fail and access will be denied, as (hopefully) no one outside the server knows the secret and therefore can't create a valid token. If the client knows the secret, esp. in browser/js envrinoments and with symetric hashing algorithmns, it's a big security risk and someone could steal the secret and create a new token with a valid signature.
Any bearer token should only be used over HTTPS. And TLS, which secures the HTTPS connection has integrity checks built in to prevent modification in transit.
So there's no need to verify the token on the client side.
Also it' better to treat the JWT token as some opaque string. This allows the issuing server to encrypt its content without breaking your application.
As others have pointed out, the client should never be in possession of the signing key, because the client can never be trusted.
Now, if the token is signed with an asymmetric key, you could download the public key and verify the token without compromising the security of the system. There are JavaScript libraries out there that can do this, but there's no reason you should be doing this.
So, right now I'm building an API for third parties uses and I was reading about RS256 and HS256. What I understood was that diff between is that in the first one you use a public key to verify and a private key to sign, and the other one, use just one key.. So if you use RS256 if because you want to keep your secret key secure and want the client to verify the token, but what I don't understand why you would like to verify the token in the client? Because you do a post request to the server, then it sends you back a token and whenever you want to make an authorized request you just use that token and the server verifies it and let you continue if its ok. So, why you would like to verify the token in the client? I thought it was a backend's duty.
I think maybe I'm wrong in something, hope you help clear this. Thanks.
EDIT:
So, my question is, I know the differences between RS256 and HS256 but what I don't understand it's the flow of how is use it. Right now I'm developing a third party api, and I just need to return a token when the client ask for it and then in the request that needs it, just verify from the server if it's a valid token. From what I understand, RS256 it's used when you want to verify your token from the client, if that's right, someone can give me an example of when or why would you want to verify the token in the client?
Use RS256 when:
tokens are signed by a third party, usually an Identity Provider(e.g. oauth2/oidc), and you need to verify that the token has been issued by a trusted entity
tokens are signed by clients, usually to get access to an API, where clients have previously registered the public key
tokens are signed by a centralized authentication server in a SingleSignOn system and they are used to get access to several federated servers
tokens are used to transfer data between two parties, not neccesarily for authentication purposes, and the signature is used to ensure the identity of the signatory
Use HS256 when:
tokens are signed and validated by the same server
I want the ability to prove to a third party (not myself) that I received some given content from a given https server, or in other words, have a signature of that content that can be verified against the public key of the SSL certificate of a website.
According to this, it seems that a signature of the digest of the data is being sent and I am hoping that this is happening every time a page is loaded. If that is right, how/where can I see/extract that signature? (e.g. using curl, whatever command line, tool...)
If my last assumption is inaccurate, is there a way that I can produce the proof described above? And if so, how?
Thanks,
TLS uses data integrity control mechanism, but as the name suggests (TLS = Transport Layer Security), TLS is about protecting the data channel, not about "signing the data". TLS guarantees (or attempts to) that what has been sent via the protected channel remains unchanged in transit and it has not been altered by the third party. So you don't need to manually check any signatures besides the validation procedure performed by the TLS client on your behalf. If you trust your TLS client, then you trust the connection. You can perform additional checks of the certificate sent by the server, but you can't check the "signature of the digest of the data".
It's possible to craft a server which will calculate the signature of the data and put the signature to the response headers, but out of the box I didn't see any server doing this (or any client verifying such signatures).