I am creating an asp.net API and I intend on using HMAC authentication to validate incoming requests.
Each user will have public and secret key. The secret key is used to add encrypted value of public key in query string named signature and public key also in query string.
When an user makes a request I am encrypting the supplied public key in the query string with the secret key I am getting from the database on server side.
If there is a supplied signature in the query string that matches my encrypted string then I am allowing user to access the API, otherwise I send an unauthorized request error.
However my problem is when calling the web API method using jQuery, the secret key is visible on client side because I am using CryptoJS to encrypt the public key.
So I have to move encryption logic to server side. Best way to avoid secret key on client side JavaScript?
Related
I'm trying to understand token based authentication. I've already created a simple app that demonstrates token authentication using OWIN, and I got it to work. I got it from here:
token-based-authentication
However, I'm still confused how exactly does my web api know that the token is valid. My understanding is that the server does not save anything in the memory (in regards to the token); when it gets the token from the client, it will somehow decrypt it, and figure out if it is valid; basically, everything needed to validate the token is in the token itself? Does it use a key to decrypt?..and if so, if I run my web app in two servers, does that mean both servers will have the exact same key?
The token is encrypted (or signed) using a key that only that server has. If it can decrypt it, then logically, it must have originated from that server, therefore it must be a real, valid token.
To use the token across multiple servers, they will need the same key; otherwise they cannot decrypt it or verify its signature.
If signing is used, a public/private key pair can be used, meaning a token generated on another server can be trusted if its public key is known. You would not need the private key to verify the signature.
The exact mechanism for doing this depends on the technologies in use.
To login to the application user credentials (login and password) have to be encrypted using the RSA public key. The public key could be extracted from the response to one of the requests. How can I encrypt user data using the extracted public key?
You can use JDK Security API in order to generate a signature based on the input data.
There are a lot of tutorials over the web with the example code you can re-use in JSR223 Test Elements using Groovy language
Here is context:
I am using PGP to encrypt messages in a chat web app. After going through some articles, I get brief idea how PGP works and here is how I am doing it with openPGPJs :
Client(web browser) generate the public/private key-pairs and send public key to server to store it.
Sender use receiver's public key to encrypt data and send it.
Receiver use their own private key to decrypt the message.
As a chat app I need to store all messages and decrypt them when user wants to see old message. decryption of messages need the private key. here the client is web browser which neither can store the private keys for long nor can keep them safe. so I decided to store the private key on web server. Now client(web browser) asks server for the private key whenever decryption of message needed.
Considering PGP an End to End protocol, storing private key on server is vulnerable. my question is:
How PGP encryption works for web based applications where client is not able to keep private key safe and confidential?
Is it Okay to store private key on server?
Is there any better way to do this?
Thanks for any suggestions.
I am working on a project where mobile apps connects to website through a set of API's. I considered creating API's using "Generic Handlers". This was seems to be working fine until restriction are defined for sensitive data. User has to be authenticated before he makes request for data.
I created a login API where user credentials are validated and a encrypted string which contains the same credentials which he provided at the time of login are returned back to the user after successful validation.
Each time a user makes request after successfull login, an encrypted string was supplied back to server in header. On server side, the encrypted data is decrypted and validated against with the credentials stored in DB. This step is unnecessary as user is recently authenticated. Is there anyway I can avoid authenticating user for each requests. I am planning to go with WCF services where Session can be effectively used to achieve the same (is this is something good idea?)
I did the same steps as you are doing for my API's. Here are some of the changes I made in the authentication part.
Client sends his credentials (username and password) to /api/login
Server validates the credentials and forms an encrypted string with identify of user and some necessary data like expiry date. Call this as token.
var tokenStr = "user_id=1234;expire_date=" + DateTime.Now.AddMinutes(20).ToString();
var encToken = AESCryptoService.Encrypt(salt, tokenStr);
Return this encrypted token to the client
Client sets this token in the HTTP header (X-App-Token) to make future API calls.
Server detects and decrypts this token. Here you can trust this token if decrypts with your salt. Get the user_id and set the current thread principal and proceed with the request.
If the token expires (read expire_date) then return 401 Authentication request, so that the client can request the token again.
You can also use SHA-1 or MD5 or some signing/encryption mechanism to make sure that the token string cannot be altered other than you.
I want to make my ASP.Net site authentication seamless using Ajax call.
So I consider using client side authentication service of microsoft that should be used via HTTPS because it sends username and password in plain-text format.
And the problem is that I can't use SSL in my site.
So I found a way to hash data before passing to web service that is described here
but the problem is there is a salt in DB that should passed to client for creating hashed password (that equals to DB saved password). and this is not safe.
Is there a better way for doing that?
I found a way.
We will use RSA for encrypting username ans password.
in summery I'll have a web service that creates RSA keypair and save it (this key will be regenerated every day to be more secure).
I will have a textbox or hidden field that calls this service and get the public key.
the for encrypt username and password with jCryption library client side and pass this to my authentication service using ajax call.
so the server will decrypt them with private key and the authenticate user.
I found a way.
Check this out: Secure AJAX Authentication without SSL
Just in case you were looking for an ASP.NET version of jCryption for bi-directional communication, which you mentioned you tried, you can find one on GitHub here: jCryptionNET