The question is really that how can an auth server that serves JWT be used by multiple websites of same company or domain (with the websites as sub-domains), for example? Not something for the public.
Already, I'm thinking of asymmetric JWT. Also, I don't want to implement OAuth 2.0 in order to avoid complexity and because the auth server would only serve web apps that are sub-domains of a same root domain.
seeking for less complex solutions based on the current description in this post
If you want a reliable and secure way to share resources between different sites, you might want to look at IdentityServer.
In a nutshell, you basically redirect anonymous user to identity server to login. After successful login, it will return a token to the user. Then the user uses that token to access resources from different sites.
Look at the basic workflow and screenshots at my GitHub sample project.
Ok so here is the deal.
Can multiple web apps access the same database (identity db or otherwise)? Of course! Now if you are using Entity Framework (and I assume you are though it wasn't stated) then this can get tricky as far as migrations etc. Personally I use Dapper so I never have to worry about that :-)
Yes the apps can each access the db but that is WAY different from from SingleSignOn which is really what you are talking about. You want a user to log in to one site and that identity to persist to other completely different sites. That's not nearly as simple as simply accessing a db. IdentityServer is virtually the standard for this kind of thing for many reasons.
No, the ajax approach will not work because when the user logs in at site1 the cookies are for site1. If he goes to site2 the browser does not have any cookies associated with site2 even though you sent credentials via ajax. The user was on site1 when this all happened so all cookies are site1 cookies, totally separate from site2 cookies. Even if you can find a way to make this work it would pose a serious security risk.
You could conceivably do something like this using hidden IFrames instead of ajax because you can set the iframe's site's cookies while you are there. But I don't recommend you do this as there are security risks involved.
You need to separate the idea of "Authentication" from the ideas of "Authorization" and even "User Management".
Authentication---- Am I who I say I am? (check my usename and password and maybe even additional form like text message etc)
Authorization---- Ok you know who I am, but what can I do on your site? This can vary from site to site. Maybe I am an admin on one of your sites but just a regular user on another. My individual site cookies will includes roles etc and they are different for each site.
User Management---- Can I change my name/email/etc?
The best way to handle this is to use a separate server app running IdentityServer. This handles the authentication and builds out the cookies for all of your sites at once. Ideally you should also use this for any user management but that can be a pain and isn't as vital. Here are a few sample apps for IdentityServer4.
Response to your Update 2----
Not exactly... Here is the basic flow: User goes to site1 and clicks "login". This fires a "challenge" which redirects them to website-auth. On website-auth the use submits their credentials (username/pw) via form post. This logs them in to the website-auth but then also redirects the user back to the original calling app (site1 in this case) with everything they need. Let's say the user now goes to site2, they are already logged in!!! Using IdentityServer4, the user will become logged in to all of the sites sorta automatically. You won't have to do extra stuff they way you described, just plug in the necessary stuff and let IdentityServer4 handle the rest.
Look, I understand that IdentityServer4 probably looks a bit intimidating, it did to me until I began working with it. Truth is, all of the hard stuff is handled for you. There is still a decent amount of configuration involved in getting it set up but it really is the best solution for what you are looking for.
Check out these quickstarts: https://github.com/IdentityServer/IdentityServer4.Samples/tree/release/Quickstarts
Response to Update3------
I understand the concern of relying on a third party and how that can seem like a questionable practice, especially when it comes to security. My response is this:
These guys are the EXPERTS in the field. So much so that IdentityServer has become the defacto security solution even in the basic templates Macrosoft provides.
Any home grown solution you will come up with will have more security holes that what IdentityServer has. This is not a slight on you at all. These guys know what they are doing. They have been doing it for years.
Why reinvent the wheel? You will spend 10x (at least) as many man-hours trying to come up with an alternative that, in the end, will still not be as good.
If what you were doing was a single website cookie based authentication then using identity really isn't necessary. Identity can do that, but there are other simple alternatives. But when it comes to multiple sites and SSO, and I really can't emphasize this enough, IdentityServer is the way to go.
The answer is a microservices auth serve that generates RSA/Asymmetric JWTs with a private key and the other servers each have the same counterpart public key to validate the JWT and retrieve the user claims.
But that solution doesn't not cater to the situation where each of those other servers need a different set of claims about about a user.
It is also not a single sign-on approach. So, I'll be back.
But OAuth 2.0 seems to be the answer, but it is too complex for my liking.
I am using asp.net mvc 2.0 and I am wondering how secure is it to put information in a cookie?
Like I put in my cookie a forms authentication ticket that is encrypted so can I put information that could be sensitive in there?
string encryptedTicket = FormsAuthentication.Encrypt(authTicket)
HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
Like I am not storing the password or anything like that but I want to store the UserId because currently every time the user makes a request to my site I have to do a query and get that users Userid, since every table in my db requires you to use the userId to get the right row back.
So these start to add up fast so I rather have it that if a user is authenticated once then that's it till they need to be re-authenticated again. If I would store this userId I could save so many requests to the database.
Yet I don't want it floating around in clear text as potential someone could use it to try to get a row out of a database when they really should not be.
Show how good is this encryption that Authentication uses?
The encryption is good enough, that's not the weak link.
The weak link is that the cookie value could be intercepted, and someone else could impersonate the user.
So, the information in the cookie is safe enough, but you can't protect the cookie itself.
The title of your question doesn't really match what you are asking. There are two different things you are asking here.
1. Is there a secure way to store data in a cookie?
The answer is yes. To safely store data in a cookie you have to encrypt the data you want to store then sign the encrypted data. Encrypting it prevents attackers from being able to read the data, signing it prevents attackers from modifying the data. This will ensure the integrity of the data. You could use this method to store data about the user you want to keep private (their email address, date of birth, etc). Note: Securely storing data in a cookie is not a safe way to authenticate a user! If you stored the user id of the user in the signed and encrypted cookie, nothing prevents an attacker from stealing the entire cookie and sending it back to the server. There's no way of knowing if the authentication cookie came from the same browser where the user entered their user name and password. Which leads us to the second question (the one you were actually asking)...
2. Is there a secure way to authenticate a user with a cookie?
Yes. To securely authenticate a user you must combine the techniques from question 1 with SSL (https). SSL ensures that only the browser will be able to access the authentication cookie (the signed encrypted cookie with the user id in it). This means that your login process (accepting the users name and password, as well as setting the authentication cookie) must happen over SSL. You must also set the HttpCookie.Secure property to true when you set the authentication cookie on the server. This tells the browser to only include this cookie when making requests to your website over SSL. You should also include an expiration time in the encrypted auth cookie to protect against someone forgetting to log out of your site while they are at the library. A side affect of this approach is that only pages on your site that are SSL will be able to authenticate the user. Which brings up a third question...
3. How do you securely authenticate a user without using SSL?
You don't. But you do have options. One strategy is to create two auth cookies at login, one regular cookie and one that is ssl-only (both encrypted and signed though). When performing sensitive operations on the users behalf, require the page be in SSL and use the SSL-only cookie. When doing non-sensitive operations (like browsing a store that is customized based on the country their account is in) you can use the regular auth cookie. Another option is to split the page so that information that requires knowing who the user is is retrieved async via AJAX or json. For example: You return the entire page of the blog over http and then you make an SSL AJAX request to get the current users name, email, profile pic, etc. We use both of these techniques on the website I work on.
I know this question was asked almost a year ago. I'm writing this for posterities sake. :-)
Along with cookie encryption, you should also implement a rotating token to prevent replay attacks.
The idea being that the encrypted cookie contains some value which can be compared to a known value on the server. If the data matches, then the request succeeds. If the data doesn't match then you are experiencing a replay attack and need to kill the session.
UPDATE
One of the comments asked if I meant to store the value in the cookie. The answer is yes. The ENTIRE cookie should be encrypted, which can be automatically done through the use of an HttpModule. Inside the encrypted cookie is any of your normal information + the changing token.
On each post back, check the token. If it's valid, allow the transaction, create a new random token, store in the cookie, and send that back to the browser. Again, in an encrypted form.
The result is that your cookie is secure (you are using 3DES?) and any attacker would have an extremely limited window of opportunity to even attempt a replay attack. If a token didn't pass muster, you could simply sound the alarm and take appropriate measures.
All that's needed server side is to keep track of the user and their current token. Which is usually a much smaller db hit than having to look up little things like the users name on each page load.
UPDATE 2
I've been trying to figure out whether this is better or worse than keeping the changing value stored in session. The conclusion I've come to is that storing a rotating value in session on the web server does absolutely nothing to prevent replay attacks and is therefore less secure than putting that value in a cookie.
Consider this scenario. Browser makes request. Server looks at the session id and pulls up the session objects, work is then performed, and the response is sent back to the browser. In the meantime, BlackHat Bob recorded the transaction.
Bob then sends the exact same request (including session id) to the server. At this point there is absolutely no way for the server to know that this is a request from an attacker. You can't use IP as those might change due to proxy use, you can't use browser fingerprinting as all of that information would have been recorded in the initial exchange. Also, given that sessions are usually good for at least 30 minutes and sometimes much longer, the attacker has a pretty good sized window to work in.
So, no matter what, to prevent replay you have to send a changing token to the browser after each request.
Now this leaves us with the question about whether to also store values such as the user id in an encrypted cookie or store it server side in a session variable. With session you have concerns such as higher memory and cpu utilization as well as potential issues with load balancing etc. With cookies you have some amount of data that is less than 4kb, and, properly done, in the 1kb or less range that gets added to each request. I guess it will boil down to whether you would rather add more / larger servers and internal networking equipment to handle the requests (session) or pay for a slightly larger internet pipe (cookie).
As you've stated, a good practice for storing any data in cookies is to encrypt the data. Encrypt before putting into the cookie, and decrypt after reading it.
In the example of storing a user identifier, choose something that's not likely to be used against your system. For the user id, use a guid rather than the likely incrementing integer that's the PK on the database table. The guid won't be easily changed to successfully guess another user during an attack on your system.
Once the user has been identified or authenticated, go ahead and store the user object, or key properties in Session.
In an ideal world with an ideal cipher this wouldn't be a problem. Unfortunately in the real world nothing is ideal, and there never will be an ideal cipher. Security is about solving these real world threats. Cryptographic systems are always vulnerable to attack, weather it be a trivial(brute force) attack or by a flaw in the primitive its self. Further more it is most likely that you will botch the implementation of the primitive, common mistakes include non-random or null IV, Key management, and incorrect block Cipher mode.
In short this is a gross misuse of cryptography. This problem is best sovled by avoiding it all together by using a session variable. This is why sessions exist, The whole point is to link a browser to state data stored on the server.
edit: Encrypting cookies has led to the ASP.NET oracle padding attack. This should have been avoided all together by using a Cryptographic Nonce. Like i said, this is a gross misuse of cryptography.
For your very specific scenario (user id), the short answer is NO!
For the long answer, imagine this hypothetical scenario:
You navigate to stackoverflow.com;
Fill your username/password and submit the form;
The server sends you a cookie containing your user ID, which is going to be used to identify you on the next requests;
Since your connection was NOT secure (HTTPS), a bad guy sniffed it, and captured the cookie.
The bad guy gains access to your account because the server didn't store, let's say, your IP address, and thus, can't distinguish between your machine and the bad guy's.
Still in this scenario, imagine the server stored your IP address, but you're on a corporate LAN, and your external IP is the same of another 100 machines. Imagine that someone that has access to one of these machines copied your cookie. You already got it, right? :-)
My advice is: put sensitive information on a HTTP session.
UPDATE: having a session implies a cookie (or at least an ugly URL), thus leading us back to the very same problem: it can be captured. The only way to avoid that is adding end-to-end encryption: HTTP+SSL = HTTPS.
And if someone says "oh, but cookies/sessions should be enough to discourage most people", check out Firesheep.
It's okay (not great, but not wrong) from a security standpoint. From a performance standpoint, however, it's something you want to avoid.
All cookies are transmitted from client to server on every request. Most users may have fast broadband connections these days, but those connections are asymetric — the upstream bandwidth used for transmitting cookie data is often still very limited. If you put too much information in your cookies, it can make your site appear sluggish, even if your web server is performing with capacity to spare. It can also push your bandwidth bill up. These are points that won't show up in your testing, which most likely happens all on your corporate network where upstream bandwidth from client to server is plentiful.
A better (general) approach is to just keep a separate token in the cookie that you use as a key to a database lookup for the information. Database calls are also relatively slow (compared to having the information already in memory or in the request), but primary key lookups like this aren't bad and it's still better then sending the data potentially a quarter of the way around the world on every request. This is better for security as well, because it keeps the data off the user's machine and off the wire as much as possible. This token should not be something like the userid from your question, but rather something more short-lived — a key used to index and hide away larger blocks of data, of which your userid is perhaps one part.
For your userID, which is likely only a single integer, as well as other small and important data, keep it in memory on the web server. Put it in the session.
The use you are looking at is the exact intended purpose of being able to store information in the Forms Auth Ticket.
No. It have been shown with Padding oracle attack that receiving encrypt data (CBC) can be dangerous because of the errors leakage.
I'm definitely not a crypto expert but I recently saw a demo where encrypted view-state was decrypt using this attack.
Encrypting the userid value in the cookie only prevents the user from knowing what the value is. It does not
prevent cookie replay (use SSL to
prevent an attacker from intercepting
a victim's cookie)
prevent tampering
(an attacker can still blindly flip
bits in the encoded cookie with a
chance that it will decode to a valid
userid, use an HMAC to prevent this)
completely prevent a user from getting the decrypted value (the user can brute force the value off line, use a strong encryption key to make success less probable)
Encrypting the cookie also introduces a key management problem. For example, when you rotate the encryption key you have to make sure "live" sessions with the old key won't immediately fail. You thought about managing the encryption key, right? What happens when admins leave? It's compromised? etc.
Does your architecture (load balancers, server distribution, ...) preclude using server-side session objects to track this information? If not, tie the userid to the session object and leave the "sensitive" data on the server -- the user only needs to have a session cookie.
A session object would probably be a lot easier and more secure for your stated concern.
To ensure proper auth cookie protection, you should make sure that you specify a secure encryption/hashing scheme (usually in the web.config) by setting the machineKey validation="SHA1" property (I use SHA1 but you can replace that with a different provider if desired). Then, make sure that your forms auth has the protection="All" attribute set so that the cookie is both hashed AND encrypted. Non-repudiation and data security, all in one :)
ASP.NET will handle encrypting/decrypting [EDIT: only the auth cookie!] the cookie for you, although for custom cookies you can use the FormsAuthentication.Encrypt(...) method, so just make sure that you're not sending the UserId via other cleartext means like the querystring.
HttpCookie c;
c.Secure = true;
Obviously this only works when transmitting via SSL, but this setting tells the browser not to send the cookie unless the connection is SSL, thus preventing interception via man-in-the-middle attacks. If you are not using a secure connection, the data in the cookie is totally visible to anyone passively sniffing the connection. This is, incidentally, not as unlikely as you'd think, considering the popularity of public wifi.
The first thing to address is whether the connections involved are secure. If they are not, assume the cookie or anything else between you and the client will be intercepted.
A cookie can be a liability once it is on the client machine. Review cookie theft, cross-site request forgery, confused deputy problem.
Cookies limitations: size, may be disabled and security risk(tampering). Of course if you encrypt cookie, there could be a performance hit. Session and Viewstate would be good alternative.
If you want it to be stored at client side, viewstate would be better. You can encrypt the string userid and store in viewstate. Session would be best option.
If your database calls are slow, consider caching
Viewstate
What I am looking for is way / design to track a user / site visitor without the need for cookies or JavaScript as about 5% of users have one or both of these turned off.
What I would like to achieve is a unique reference for the user which can be captured server side in code.
I was thinking machine CPU / Motherboard ID but this information is hidden.
What information could you use / combine to create a unique hash.
I also need that ID to work across different sessions. Or maybe if the information is unique enough a way to do cookies/cookie type things across different browsers.
You could put a code in the url, this is how cookieless sessions used to work (maybe still do).
UPDATE: taking comment on, depending on your application and number of users you could consider giving each user a dedicated sub domain, or if subdomains are too tricky build it as part of their url. This depends on whether they need to login into the site.
You could look at doing something with client ip addresses but this would not work for everyone.
Are you sure the users really have Cookies switched off? It could be that users have persistent cookies switched off (the ones that write a file to the user's hard drive) and still have browser session cookies switched on. Browser Session cookies live in memory and disappear when the user closes their web browser, but normally this is enough for server-side Session State to work properly.
In nearly all cases where clients have cookies disabled, it's always persistent cookies only. The in-memory ones are still enabled and work fine, you can still track users, but only for as long as the browser remains open, this might be enough for you I don't know.
Update: I just noticed you said this needs to persist across sessions (as in user closing browser down and going back to site later). Have you looked at HTML5 storage options (LocalStorage in particular), it's a simple Key/Value store, and it's reasonably supported across browsers even versions of Internet Explorer.
After some more research aided by Rup and the ret of the comments on here, it has become apparent that there isn't a simple way to track a user across your site without cookies, But its not impossible.
Looks like the only way to truly achieve this is via browser finger printing, using all the information supplied back to the server to make a unique finger print of the users browser, this seams to work for about 95% about the same as cookies.
Browser finger printing at the moment seams like a workable approach but I feel there might be quite a large backlash from the general public / privacy groups if you where to go down this route.
For the moment it seems we are stuck with cookies.
I have to design a CMS where a set of credentials can only be used once. So if a user has logged in from his computer, no-one can login with his credentials from another location until that user logs out.
Now using the asp.net membership provider out the box, the IsOnline method returns a boolean that reflects the timeout window vs. the last activity date. This is not a viable option for me, because if the user just closes the browser after logging in, IsOnline will still be true. But his session will be destroyed(assuming he's not using Remember Me) so if he tries to log in somewhere else it will say "Sorry you still logged in".
Are there any hard and fast options for doing this..?
I was thinking of forcing the users to be "Remembered" so when he logs in a boolean "IsReallyOnline" will be set to true and vice versa when he logs out.. Although this option has it's limitations, (people turn off cookies, not logging out and closing the browser then sum1 else comes and browser to the site and he's logged in etc....) it seems like the most viable for now?
Any suggestions?
Thanks in advance
You are really asking for something that is outside of the remit of the web. The HTTP protocol is by definition stateless, meaning that at any one time; a server never need know if a client still exists. The newer/older implementations of web server programming languages (e.g. php / asp.net mvc) for the most part shy away from storing any state about connected/active clients.
Some things to ask yourself include:
How long may a user be 'active' on a page without causing a postback? Javascript based pages may allow for a user to interactively be using a page for quite some time before any kind of postback happens.
Will the users be going through a proxy or caching server? Multiple requests from 'different' users may come from the same machine in this case.
Will your application be running on one machine only, or maybe a server farm? You'll need to ensure that load balancing (for example) doesn't punt different users onto different servers allowing multiple logins.
How about a user legitimately using two different browsers on the same machine? Is this to be allowed?
One might suggest your problem here stems from trying to use the wrong technology given your requirements? Maybe writing a client application which uses direct connection to your servers would be more 'secure'? (Yes I understand this is huge hassles but if your one user / one logon requirement is absolute maybe you could explore this avenue?)
Oh alright, a web solution
For a http centric solution you could try a javascript timer making a request to your server every X seconds to indicate that the session is still active. As long as the browser is open and the network connection valid you should be getting these 'pings'. The session is kept open by the cookie passed by the httprequest.
You'll be able to code the 'ping' page to store the user details into either the application object or some membership provider of your choice then interrogate this provider whenever a client attempts to log in.
This will require a relatively short time-out on a session or some other mechanism to ensure that a crashed browser doesn't lock your legitimate user out for too long.
Please note: This will fail horribly if the user doesn't have javascript turned on (Don't assume that they will have!)
Fast Option: Store IsOnline as a session.
Check if session is true, then allow. If not, don't allow.
If user closes browser, he will be logged outas its in a session.
I would like to hear some opinions about using the isolated storage in Silverlight for storing sensitive data. For example, is it OK to store an authentication token (some GUID that identifies a server-side session) in this storage, or is it better to use cookies?
The isolated storage gives an advantage over cookies in that it is shared across browsers, but it might be more difficult to handle expiry, and there might be some other issues (security?) that I am not aware of.
So... what are your opinions? Or do you know any great articles about the topic?
Thanks, Jacob
I've just started on a Silverlight project that uses Isolated Storage to store a login token that formerly was stored in a cookie when the app was written in ASP.NET.
The only thing I noticed with the end result was that each type of browser would remember the same user (as opposed to the cookie solution where every browser had it's own cookie store and it's own idea of who was logged in).
Security is not going to be substantially different - if you feel inclined to - encrypt the token. Though really why would you bother? If any process has access to a person's private AppData they're going to have access to all sorts of confidential information.
The app's url determines access, so no one can get at the data unless your domain name expires.
Other than the advantage of sharing the token across multiple browser instances, which I personally haven't ever seen the need for, I think I'll stick to using cookies for now. Why? Because they are better supported by intermediaries like proxy servers and HTTP accelerators. In general I adopt a "use the standard" rather than a "roll your own" approach - it results in less code to maintain and more familiar code for new developers.