Looks like the solutions out there for securing ASP.NET Web API is pretty scattered, so I decided to roll my own public/private key encryption scheme. Please take a look at my workflow and help me answer a question I'm stuck on at the end. (Again, it's specific to .NET 4.0 Web API framework)
User register at my Web MVC 4.0 website.
Once registered, my website does 4 things
a) Generate a RSA server public key for this user
b). Generate a RSA server private key for this user
c). Generate a RSA client public key for this user
d). Generate a RSA client private key for this user
I save all 4 keys to this user account in database and give the user the server public key, called the "APIKey" as well as the client private key, called "SecretKey". This is for future handshake purpose. User will never know about the server private key nor the client public key.
Once user confirms they have the keys, I delete the "client private key" from my database for security purpose.
User starts to request my WebAPI authentication service by submitting the server public key (or APIKey)+":"+encrypted message of (username,password) using the RSA server public key (APIKey)
Server receives the APIKey+":"+encrypted message, find the private key, decrypt the message, get username,password, and use Membership provider to make sure they are correct.
If not correct, then create a denied response. Otherwise, it finds the Client Public Key on record for the user, create a unique time sensitive session token (expires in 5 minutes), record it in database + time created, and use the client public key to encrypt the token and send it back to the client.
Client receives the response, use it's "Client private key" or "Secret Key" to decrypt the response, get the token.
User makes other requests to the service by using Server Public Key to encrypt the following
a) session token
b) timestamp (so I can make sure replay attack doesn't happen)
c) data
and send to the server its APIKEy+":"+encrypted message
What i'm stuck on is step 9 and beyond.
Is that necessary at step 9 to still use public / private key to communicate? The reason I'm asking is because browsers communicate with servers through SSL, at the end, once handshake happens, they use an agreed cipher suite symmetric algorithm to pass message back and forth, supposedly it's faster? But if we do that, will it be secure from this point on wards?
In that case, where in my workflow can I exchange this agreement between my Web API and Client to use the same symmetric algorithm to encrypt/decrypt information back and forth?
Thanks!!
Edit: If you see a flaw in this workflow, please do let me know! Greatly appreciate it.
You are probably looking to make a secure authentication without need for domains/user auth so you want server client cert exchange right? ATK is right if you just want encrypted traffic (which you should use anyway for the exchange), but for actually using it as auth, this article is really useful: http://codebetter.com/johnvpetersen/2012/04/02/making-your-asp-net-web-apis-secure/
Please don't roll your own scheme. Crypto is very hard to get right, even by the experts. A very subtle error can completely remove all security provided by the scheme. Just look at the attacks on SSL/TLS over the past few years for examples.
You mention a "web api" but it's unclear exactly what protocol you are using. If you are using SOAP, use "Web Security" (WS), which is well defined for SOAP. If you are communicating over HTTP (ex REST), use HTTPS. If you are communicating over a connected channel, use TLS or SSH.
EDIT: Per http://msdn.microsoft.com/en-us/library/hh833994(v=vs.108).aspx,
ASP.NET Web API is a framework that makes it easy to build HTTP
services that reach a broad range of clients, including browsers and
mobile devices. ASP.NET Web API is an ideal platform for building
RESTful applications on the .NET Framework
This means you probably want to use HTTPS.
Related
I want to setup secure interaction between my server and clients and I would like to avoid inventing square wheel.
There is a "REST-Server" in SpringBoot
Service has many "REST-clients" in Java installed somewhere. I don't control it.
"REST-Server" generates public/private key pair for every(!) client and shares pub key with client
every "REST-client" generates it's own public/private key pair and shares public key with "REST-Server". Client shares it's public key along with unique id.
"REST-clients" poll ""REST-server" from time to time
"REST-client" sends request in from:
clientId (helps "REST-Server" to locate right client pub key to decrypt message)
payload encoded with "REST-Server" public key assigned for a given client
original message SHA so "REST-Server" can verify if payload was decrypted correctly
client signature created with client's private key, so server can verify if message comes from authorised client
"REST-server"
locates private key associated with a client by "uniqieId"
decrypts and verifies it with SHA
verifies sender with client signature and known client's pubic key
"REST-server" sends response in form
payload encoded with "Client"'s public key
original message SHA so "client" can verify if payload was decrypted correctly
"REST-client" decrypts response using own private key.
Is there any library / spingboot extension that can do most parts of it?
I would focus more on the client angle than the server one:
Some clients can keep a secret (back end / confidential clients)
Some clients cannot (web / mobile UIs - public clients)
If a client API credential is compromised then you may have a permanent security breach
This feels like a problem that OAuth 2.x solves:
Supports both type of client
Apps work with tokens and never use API credentials directly
Even if a token is stolen it expires shortly after
Threat models are reviewed by experts
In Java I would use a respected OAuth library such as NimbusDS.
I have a mobile app which talks to an ASP WebAPI on the back-end.
I've implemented the token flow authentication (with the help of Taiseer's guide).
Still there is one concept I can't grasp my mind around: CleintId and ClientSecret.
From what I understand the client secret (along with client id) is meant to
block access to the end point in my API that produces tokens. This way the end point is protected from malicious users trying to poke around the API and try to gain some information by invoking it with various inputs.
Meaning, only clients which hold the secret can start an authenticaon flow. And in my case, I have only one client which is a mobile app, and it's secret is stored in a secure place (KeyChain for iOs). But I've read that those key chains can be easily dumped and dissect for the secret.
So the conclusion I came up with, is that I can get rid of the whole client secret logic, mainly leaving ValidateClientAuthentication() blank:
public async override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
{
context.Validated();
return;
}
And to me it dose not seem like a security hole, but just a thin layer in the flow that is gone now. Because, again, the client secret can be easily revealed by any malicious user holding a mobile device with the app installed, and once he gets it this layer of security is useless.
Are those assumptions are incorrect ?
Can I leave the ValidateClientAuthentication() method blank ?
As you already figured out, mobile applications cannot keep their credentials private because they can be extracted from the application binaries. Not to mention that requests can be easily intercepted using a proxy server and a traffic analyzer like Fiddler or Wireshark.
With the authorization code flow (1) or the resource owner password credentials grant, client authentication is not mandatory if the client cannot safely store its credentials and thus cannot be considered as a "confidential" application (see https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3 and https://www.rfc-editor.org/rfc/rfc6749#section-4.3.2).
For non-confidential applications, it's safe to call context.Validated().
Personally, I try to avoid the resource owner password credentials grant as much as possible as it clearly defeats the purpose of OAuth2: keeping your password confidential and giving constrained authorizations. If your app is fully trusted, it shouldn't be a problem, though.
In practice, using the authorization code flow without enforcing client authentication is extremely rare, as it's simpler to use the implicit flow with mobile client applications, that offers a similar security level in this case (not to mention that it avoids a second roundtrip to the token endpoint).
I have been reading about JWT.
But from what I read it is not an authentication mechanism but more like a crucial component in a Authentication mechanism.
I have currently implemented a solution which works, but it was just to try out JWT and see how it works. But what I am after now is how one should make use of it. From my experience of it its basically just an encryption mechanism that gives you a unique encrypted key. You are also able to put information inside of this token.
I am wanting to implement it in terms on a ASP.NET web api 2 to be consumed by a mobile application.
So step 1:
app => Server : Login (user, pasword)
Server => app : Login OK, heres your JWT
app => server : Get my profile (sends JWT with request)
Server then decrypts JWT and determines the requests Identity.
Now this is just my understanding of it, Look I could be on the totally wrong path.
Is the Ideal of JWT so that you dont have to authenticate on every request? I just authenticate the users credentials once (on the initial login) and there on after the server can simply use JWT and no have to lookup the users pw and user in the DB?
I just want to use the JWT to Identity who the user is. I will then authorize then after i have authenticated them. As I know there is a big confused with the new MVC and Authentication and Authorization.
So what my question comes down to.
How can I safely and effectively Implement a Authentication Mechanism Using JWT?
I don't want to just cough something up that seems to work and not have any Idea of the security implications. I am sure that there exists a source some where that has possibly designed a secure mechanism that would suit my requirements.
My requirements are:
Must only have to check db for users credentials once off per session? Due to the use of bcrypt using a lot of resources to compare passwords.
Must be able to identify the user from their request. (I.e who they are, userId will be sufficient) and preferably without accessing the DB as well
Should be as low overhead as possible, with regards to resources on the server side processing the request.
If an intruder had to copy a devices previous request, then he should not be able to access the real users data. (obviously)
Thanks
Your understanding of JWTs is good. But here are a couple corrections and some recommendations.
Authentication and Authorization
JWTs have nothing to do with authentication. Hitting your DB and hashing passwords only happens when you authenticate on creation of the JWT. This is orthogonal to JWTs and you can do that in any way you like. I personally like Membership Reboot, which also has a good example of using JWTs.
Theoretically, you could have the user enter a password once a year and have the JWT be valid that entire year. This most likely not the best solution, if the JWT gets stolen at any point the users resources would be compromised.
Encryption
Tokens can, but don't have to be encrypted. Encrypting your tokens will increase the complexity of your system and amount of computation your server needs to read the JWTs. This might be important if you require that no one is able to read the token when it is at rest.
Tokens are always cryptographically signed by the issuer to ensure their integrity. Meaning they cannot be tampered with by the user or a third party.
Claims
Your JWTs can contain any information you want. The users name, birthdate, email, etc. You do this with claims based authorization. You then just tell your provider to make a JWT with these claims from the Claims Principle. The following code is from that Membership Reboot example and it shows you how this is done.
public override Task GrantResourceOwnerCredentials(OAuthGrantResourceOwnerCredentialsContext context)
{
var svc = context.OwinContext.Environment.GetUserAccountService<UserAccount>();
UserAccount user;
if (svc.Authenticate("users", context.UserName, context.Password, out user))
{
var claims = user.GetAllClaims();
var id = new System.Security.Claims.ClaimsIdentity(claims, "MembershipReboot");
context.Validated(id);
}
return base.GrantResourceOwnerCredentials(context);
}
This allows you to control with precision whom is accessing your resources, all without hitting your processor intensive authentication service.
Implementation
A very easy way to implement a Token provider is to use Microsoft's OAuth Authorization Server in your WebAPI project. It give you the bare bones of what you need to make a OAuth server for your API.
You could also look into Thinktecture's Identity Server which would give you much easier control over users. For instance, you can easily implement refresh tokens with identity server where the user is authenticated once and then for a certain amount of time (maybe a month) they can continue getting short lived JWTs from the Identity Server. The refresh tokens are good because they can be revoked, whereas JWTs cannot. The downside of this solution is that you need to set up another server or two to host the Identity service.
To deal with your last point, that an intruder should not be able to copy the last request to get access to a resource, you must use SSL at a bare minimum. This will protect the token in transport.
If you are protecting something extremely sensitive, you should keep the token lifetime to a very short window of time. If you are protecting something less sensitive, you could make the lifetime longer. The longer the token if valid, the larger the window of time a attacker will have to impersonate the authenticated user if the user's machine is compromised.
I've written detailed blog post about configuring the OWIN Authorization server to issue signed JSON Web Tokens instead of default token. So the resource servers (Audience) can register with the Authorization server, and then they can use the JWT tokens issued by Token issuer party without the need to unify machineKey values between all parties. You can read the post JSON Web Token in ASP.NET Web API 2 using Owin
For the formal concept . The Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.
Let’s see the real life example
Imagine that your neighbor has asked you to feed his pets while he is away. In this example, you have the authorization to access the kitchen and open the cupboard storing the pet food. However, you can’t go into your neighbor’s bedroom as he did not explicitly permit you to do so. Even though you had the right to enter the house (authentication), your neighbor only allowed you access to certain areas (authorization).
For more detailed and for users who like more STEP BY STEP implementation on practical use of JSON Web Token in WEB API. This is must read post Secure WebAPI Using JSON WEB TOKEN
Updated to use: System.IdentityModel.Tokens.Jwt -Version 5.1.4
I am working on a web page that uses a lot of AJAX to communicate with the server. The server, in turn, has an extensive REST/JSON API exposing the different operations called by the web client.
This web site is used by both anonymous and authenticated users. As you might expect, the web service calls issued by authenticated users require authentication, and are thus protected from unauthorized users or applications.
However, the web site has a lot of features that require no authentication, and some of these make use of anonymous web services. The only way I am using to prevent outsiders from calling this web services is by using a CSRF token. I know, the CSRF token is not very useful in this regard... with some time in hand, you can figure out how to consume the web services even if they use a CSRF token.
Of course, you can use a CAPTCHA to prevent applications or bots from autonomously using your web service. However, any human will be able to use it.
Sharing a secret key between client and server, on the other side, would be useless. This, because of the ability of any outsider to read it from the web page source code.
I would like to make these web services as difficult to invoke as posible to any 3rd party application. What would you do besides using the CSRF token? It sounds a little stupid, but hey, maybe it is stupid and I am just losing my time.
Note: given this application uses a browser and not an "executable" as the client, this question is irrelevant to the discussion. I cannot use a secret between server and client (not to my knowledge, at least)
I would take a few steps.
Force https on the site. Automatically redirect any incoming http requests to https ones (the RequireHttps attribute is handy for this)
Each page needs to (securely, hence the https) send a one-time use token to the client, to be used for the page. The script running on the client can hold this in the page memory. Any request coming back sends a hashed & salted response, along with the nonce salt. The server can repeat the steps with the saved token + salt and hash to confirm the request. (much like explunit's answer above)
(It's worth noting that the secure request from a client isn't being authenticated from a user account, merely a token sent with the full page.)
The definition for one-time could either be session or page load, depending on your security vs convenience preference. Tokens should be long and expired fairly quickly to frustrate attackers.
The SSL + Hash(token + nonce) should be enough for your needs.
This is interesting. Below is a crazy suggestion. Remember, your question is also equally crazy.
Your website, once opened through a browser, should generate a long polling connection (Comet programing). This will create a unique session between the browser and the server. When ur JS is making the ajax call, send some token (unique token every time) to the server through the long polling thread. Let the AJAX also send the same token. At the server, get the AJAX token and check whether you have a similar token in you long polling session. If yes, fulfill the request. Any coder can break this. But, it won't be easy. Chances are the freeboarders won't even see these second piece of comet code. You can implement the comet code in such a way it is not easy to detect or understand. When they call ur service, send a 'Service Unavailable' message. They will be confused. Also make the comet code https.
You can also check how long that long polling thread is open. If the session was just opened and you get a ajax call right away, you can assume it is a 3rd party call. It depends on ur website flow. If ur Ajax call happens after 1 second of page load, you can check for that pattern on server side.
Anyone coding for your public api, will have 1 to 2 secret checks that they wouldn't even know and even if they know, they might be discouraged by all the extra coding they have to do.
You might have an easier problem than the one described in the linked question since you don't need to distribute a binary to the users. Even if your app is open source, the HMAC/signature key (in the "Request Signatures" part of that answer) can be controlled by an environment/configuration setting.
To summarize:
The secret key is not actually sent between client and server. Rather, it's used to sign the requests
Be sure that the requests include some unique/random element (your CSRF key probably suffices) so that two requests for the same API data are not identical.
Sign the request with the secret key and append the signature to the request. You linked to a PHP question but not clear if what language you're using. In .Net I would use a HMAC class such as HMACSHA256.
On the API server-side use the same HMAC object to verify that the request was signed with the same secret key.
Maybe you could use counters to keep track of conversations. Only the Server and Clients will be able to predict the next iteration in a conversation. This way, I think, you can prevent third party applications to impersonate someone (Just an idea though).
At the beginning, they start talking at some iteration (i=0, for example).
Every time the client requests something, the counter is incremented by some number in both the server side and the client (i=i+some_number).
And, after a few minutes of no communication, they both know they have to reset the counter (i=0).
This is just an idea based on the concept of RSA and also placing Fraud Detection on your system. The Risk from Authorized users is minimal however they can attempt to make anonymous calls to your web-service too.
For UN-Authorised users : For each web-service call , generate a token say using RSA which changes after some time(can be configured say 30 min). This way prediction of code is minimized. I have not heard of RSA collision till now. Send this token back to the user for his browser session. For further security , we might want to attach a session id with RSA token. Since session ids are unique new anonymous calls would require new session id.
Calls can be tracked using Auditing mechanism. Also per-web service there can be a different RSA setup. How the Algorithm for Fraud Detection would work is a challenge by itself.
For Authorized Users :
Every user should be tracked by his IP Address using Header block. The RSA token principle can be applied.
The solution is very vague but worth considering.
I'm trying to make a web service secure.
It's not for a bank or anything of that sort, but the organization using it may lose some money if the service will be used by someone not authorized (it's hard to tell exactly how much..).
The purpose is not to allow unauthorized applications to use any method (other than "GetChallenge". for users authentication there is a different mechanism which checks for username and password. I actually combined the two, but they serve different purposes):
So here's what I do:
I send a (ASP.NET) session key (for everyone to read. ASP.NET's session Is 15 randomly generated bytes, it lives for 20 minutes unless prolonged, and ASP.NET will not receive any request without it).
In my SignIn method, apart from username and password (which anyone can acquire, since it's a part of a public site), I receive a third parameter - the session key hashed by md5 algorithm with 6 bytes as salt.
And only if the hash is correct (I'm hashing and comparing it on the server side) - I let the users sign in.
From then on in every method, I check if the user is signed in.
Added: The username and password are sent as clear text, and that's not a problem (not the one I'm addressing at least). The problem is for someone (other than the company we're working with) writing an application which uses my web service. The web service should only be used by an authorized application.
Also, the session id is sent back and forth with every request and response (as a part of ASP.NET session mechanism. That's how ASP.NET knows to "track" a session specific for a user). Sorry for not clarifying that from the first place.
(irrationally thought it was obvious).
How strong and effective is that security strategy?
Thanks.
Updated based on your edit and comment
It's pretty secure and is very similar to the approach used by Google, Facebook and others for their API keys. Except...
Session ID plain text potential issue
I would recommend against using Session ID as part of a security mechanism.
The one issue is with passing the session key in plain text across the network. There is potential that this could open up some Session hijack and other attacks.
From the Microsoft Docs:
The SessionID is sent between the server and the browser in clear text, either in a cookie or in the URL. As a result, an unwanted source could gain access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing private or sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID.
As you are using the Session ID as part of your security mechanism I would say that is sensitive data.
One way to ensure someone doesn't get hold of your session key is to run your service on HTTPS. Personally I would avoid using the Session ID in this way and generating a non-related value instead.
Recommended change
Follow more closely the model used by Google and the like. Generate a new GUID for each application, store the GUID in a database on the server, pass the GUID in each request to your server from the client.
Benfits:
Identifies the client application uniquely, allowing you to track and manage usage per client nicely
Easily disable any client by removing the GUID from your data store
No sensitive data on the wire
I would still run the service on HTTPS as it's easy to setup and gives the added benefit of protecting any other data you send to your service.
The purpose of encryption is not to
allow unauthorized applications to use
any method
Wrong. The purpose of encryption it to prevent the understanding of data whilst either in transit or stored. It prevents data being 'useable' by those that do not have the means to decrypt.
What you are describing is something similar to a public/private key system. You're making your session key available to everyone. Then only after they've md5 with the correct salt (as per your server side comparison) you're then trusting that source.
You've got NO authentication here except for username and password. Also your data isn't encrypted during transit. I fail to see how this is at all secure.
I think you're best bet is to use an SSL certificate (so your web service is running over HTTPS) along with the username and password. If you want to be doubly secure you might want to go down the route of checking source IP ranges and login locations as an additional check. Perhaps a forced password change interval will help in the case that consumers are passing credentials to a third party + audit how the web service is actually being used.
As a side note if you want to hash something don't use MD5, its broken.
From a web services perspective the ideal way to use authentication or provide security to your service is something like this: Web Service Authentication (Token and MD5 Hashing to encrypt password).
The way you describe it, it does not seem secure at all.
What is the point of letting the SignIn method accept a hashed session key, if the session key is public ("for everyone to read")?
Plus: "in every method, I check if the user is signed in. " How do you check that?
A common (and reasonably secure) strategy would be to generate a (unique, sufficiently long and random) session ID server-side, and send it to the client after it has authenticated. Then check every client request and only accept it if it contains the session ID. To do this, either embed the ID into all links on every page, or set it as a cookie, depending on what's easier for you.
On logout, just delete the session ID on the server.
That way, no one can invoke any method without a valid session.