Why almost all websites out there are using cookies instead of basic auth?
It can't be only that the user/pass window is ugly and none of them is more secure. They are both insecure (without https).
To logout of a basic auth login the browser often needs to be quit entirely. This means there is no way for the server to log out the user.
I believe basic auth also has more overhead (assuming your cookie size isn't massive), but I might be wrong about that.
HTTP basic auth also sends the username and password with every request, making it potentially less secure because there is more opportunity for interception.
You have more control over cookies. You can encrypt them so that they are secure even without HTTPS. Basic auth is always unsecure over HTTP. Also cookies don't contain the password on each request. And, yes, what can I say, users like AJAX login forms and nice animated effects when logging in which unfortunately cannot be achieved with basic auth.
With cookies you have the complete control on when to authenticate the user, its not as soon as theres a request.
Plus you dont have to authenticate for pictures as well
Another thing is that you dont have to rely on a sysadmin for auth.
You also have the choice regarding the users repository with session.
There are other things. As you said, both are more or less secure so why not opt with flexibility? To showcase sites to clients we often use server auth as it is easy and a global solution.. for forms within apps, we use cookies.
Related
I have an app, client side, that uses auth0 for accessing the different API's on the server. But now I want to add another app, a single page app, I'm going to use VueJs, and this app would be open "ideally" w/o a user having to sign in, it's like a demo with reduced functionality, I just want to check that the user is not a robot basically, so I don't expose my API in those cases.
My ideas so far:
- Somehow use recaptcha and auth0 altogether.
- Then have a new server that would validate that the calls are made only to allowed endpoints (this is not of my interest in the question), so that even if somehow the auth is vulnerated it doesn't leave the real server open to all type of calls.
- Pass the call to the server along with the bearer token, just as if I was doing it with my other old client app.
Is this viable? Now I'm forcing the user to validate, this is more a thing about UX (User-experience), but I'd like a way to avoid that. I'm aware that just with auth0 I can't do this see this post from Auth0, so I was expecting a mix between what I mentioned.
EDIT:
I'm sticking to validating in both cases, but I'm still interested to get opinions over this as future references.
At the end, with the very concept of how auth0 works that idea is not possible, so my approach was the following:
Give a temporary authenticated (auth 0) visitor a token which has restricted access level, then pass the request to a new middle server, the idea is to encrypt the real ids so the frontend thinks it's requesting project A123456etc, when indeed it's going to get decrypted in the middle server to project 456y-etc and given a whitelist it will decide to pass the request along with the token to the final server, the final server has measures to reduce xss and Ddos threats.
Anyway, if there's a better resolve to it I will change the accepted answer.
You could do a mix of using recaptcha for the open public, then on the server side analyse the incoming user request (you can already try to get a human made digital fingerprint just to differentiate with a robot-generated one) and the server (more a middle server) makes the call to you API (and this server has limited surface access)
What we normally do in these situations (if I got your issue correctly) is to create two different endpoints, one working with the token and another one receiving the Recaptcha token and validating it with Google servers.
Both endpoints end up calling the same code but this way you can add extra functionality in a layer in the 'public' endpoint to ensure that you are asking only for public features (if that cannot be granted just modifying the interface).
My question is different it's rather conceptual - As when a user login, session is created on server and it stores a unique id to client(browser) what if I copy that cryptographically signed cookie and any associate data from browser like token whatever app uses to recognize the machine, paste it or create it on another machine?
How would server recognize that? could someone Explain me as much you can? that would be a help
I tried finding the solution.
or how can I secure that? :)
As far as I know, only the user-identifying token in the Rails session cookie identifies the user. By sending that token (which happens automatically on each request), the server knows who you are. Anyone having that token will be treated by the server as if it were you. This is called Session hijacking.
There are a few things you can do to protect your user's cookies. First of all, secure your cookies by setting two flags:
secure tells the browser to send that cookie only over HTTPS, so it is protected against someone reading your traffic (and your cookie).
HttpOnly tells the browser to hide that cookie from Javascript, which improves protection against XSS (Cross Site Scripting). An attacker may find a way to inject some malicious Javascript, but the browser won't give it your session cookie.
On setting these flags, see the Rails API. For custom cookies it's basically:
cookies[:my_cookie] = { value: '...', secure: true, httponly: true}
For configuring the Rails session cookie, see this answer.
Recently, I have written a middleware that sets both flags automatically to any cookie in the application. It is called safe_cookies and we're using it in order to protect our applications.
Question #1:
Is setAuthCookie any less safe than FormsAuthentication.Encrypt(ticketVariable)?
I mean if anyone tries to modify the cookie created by setAuthCookie, by modifying the username, I suppose that'll violate the authentication on subsequent calls?
Question #2:
for those using iphones and tablets to access the site, I suppose FormsAuthentication will fail? Given that I don't want to use cookieless option, is there another approach to make the site secure on both smart phones web browsers and ummm none-smartphone web browsers?
cheers
SetAuthCookie basically creates a new FormsAuthenticationTicket with the supplied username & persistence options, serializes it, FormsAuthentication.Encrypt()'s it, and sets it in the Response.Cookies collection. SetAuthCookie and GetAuthCookie both call FormsAuthentication.Encrypt indirectly.
On subsequent requests, the FormsAuthentiationModule handles the AuthenticateRequest event. If it sees a cookie (it may have expired), it attempts to decrypt it's value with the machineKey (it may have been tampered with) and deserialize it back into a FormsAuthenticationTicket (it may be corrupt). If none of that (bad stuff) happens, the ticket contains the username, issue date, expiration info, etc.. If the ticket hasn't expired, an IIdentity and IPrincipal are created and assigned to HttpContext.Current.User and Thread.CurrentThread.Principal. In .NET 4.5 and later (I think), this is Claims-based (ClaimsIdentity, ClaimsPrincipal). Prior to that, it was a (GenericPrincipal, FormsIdentity) I think.
Any tampering at all on the user side will cause the request to be treated as anonymous. It will fail to decrypt. The only things that would compromise this validation would be if the machineKey in web.config/machine.config somehow got into the hands of an attacker or if there was a bug in the framework code (search for Padding Oracle for a historical example of this).
Aside from that, the other thing to watch out for would be session hijacking. If someone steals your cookie on a public wifi for example, they can present it to the server and the server will behave as if it's you. This generally involves network traffic sniffing. For these reasons, best practice is to use SSL for your entire site and set the cookie to HTTP only and Secure (only presented over https connections) in web.config/system.web/authorization/forms. HTTP only means that it will not be available to client-side Javascript. HTTP Only and Secure effectively means HTTPS only. This will only work if you use SSL on your entire site.
FormsAuthentication will work fine on mobile web browsers. It simply requires the client to accept cookies. As far as I know, all mobile devices will allow this.
I have to implement a web site (MVC4/Single Page Application + knockout + Web.API) and I've been reading tons of articles and forums but I still can't figure out about some points in security/authentication and the way to go forward when securing the login page and the Web.API.
The site will run totally under SSL. Once the user logs on the first time, he/she will get an email with a link to confirm the register process. Password and a “salt” value will be stored encrypted in database, with no possibility to get password decrypted back. The API will be used just for this application.
I have some questions that I need to answer before to go any further:
Which method will be the best for my application in terms of security: Basic/ SimpleMembership? Any other possibilities?
The object Principal/IPrincipal is to be used just with Basic Authentication?
As far as I know, if I use SimpleMembership, because of the use of cookies, is this not breaking the RESTful paradigm? So if I build a REST Web.API, shouldn't I avoid to use SimpleMembership?
I was checking ThinkTecture.IdentityModel, with tokens. Is this a type of authentication like Basic, or Forms, or Auth, or it's something that can be added to the other authentication types?
Thank you.
Most likely this question will be closed as too localized. Even then, I will put in a few pointers. This is not an answer, but the comments section would be too small for this.
What method and how you authenticate is totally up to your subsystem. There is no one way that will work the best for everyone. A SPA is no different that any other application. You still will be giving access to certain resources based on authentication. That could be APIs, with a custom Authorization attribute, could be a header value, token based, who knows! Whatever you think is best.
I suggest you read more on this to understand how this works.
Use of cookies in no way states that it breaks REST. You will find ton of articles on this specific item itself. Cookies will be passed with your request, just the way you pass any specific information that the server needs in order for it to give you data. If sending cookies breaks REST, then sending parameters to your API should break REST too!
Now, a very common approach (and by no means the ONE AND ALL approach), is the use of a token based system for SPA. The reason though many, the easiest to explain would be that, your services (Web API or whatever) could be hosted separately and your client is working as CORS client. In which case, you authenticate in whatever form you choose, create a secure token and send it back to the client and every resource that needs an authenticated user, is checked against the token. The token will be sent as part of your header with every request. No token would result in a simple 401 (Unauthorized) or a invalid token could result in a 403 (Forbidden).
No one says an SPA needs to be all static HTML, with data binding, it could as well be your MVC site returning partials being loaded (something I have done in the past). As far as working with just HTML and JS (Durandal specifically), there are ways to secure even the client app. Ultimately, lock down the data from the server and route the client to the login screen the moment you receive a 401/403.
If your concern is more in the terms of XSS or request forging, there are ways to prevent that even with just HTML and JS (though not as easy as dropping anti-forgery token with MVC).
My two cents.
If you do "direct" authentication - meaning you can validate the passwords directly - you can use Basic Authentication.
I wrote about it here:
http://leastprivilege.com/2013/04/22/web-api-security-basic-authentication-with-thinktecture-identitymodel-authenticationhandler/
In addition you can consider using session tokens to get rid of the password on the client:
http://leastprivilege.com/2012/06/19/session-token-support-for-asp-net-web-api/
I'm getting ready to have an SSL cert installed on my hosting.
It is my understanding that (and correct me if I'm wrong...):
Once the hosting guys install the cert, I will be able to browse my site on Http or Https (nothing will stop me from continuing to use Http)?
The only thing I need to do, is add logic (in the case of MVC, Controller attributes/filters) to force certain pages, of my choosing, to redirect to Https (for instance, adding a [RequiresHttps] attribute sparingly).
Do I have to worry about doing anything extra with these things to make sure I'm using SSL properly? I'm not sure if I need to change something with logic having to do with:
Cookies
PayPal Express integration
Also, I plan on adding [RequiresHttps] only on the shopping cart, checkout, login, account, and administration pages. I wish to leave my product browsing/shopping pages on Http since I heard there is more overhead for using Https. Is this normal/acceptable/ok?
One more question... I know ASP.NET stores some login information in the form of an Auth cookie. It is okay that a user logs in within an Https page, but then can go back and browse in an Http page? I'm wondering if that creates a security weakness since the user is logged in and browsing in Http again. Does that ruin the point of using SSL?
I'm kind of a newb at this... so help would be appreciated.
Starting with your questions, on one, (1) yes nothing will stop you to use for the same pages http ether https.
and (2) Yes you need to add your logic on what page will be show only as https and what as http. If some one wondering, why not show all as https the reason is the speed, when you send them as https the page are bigger and the encode/decode is take a little bit more, so if you do not need https, just switch it to http.
Switching Between HTTP and HTTPS Automatically is a very good code to use for the implementation of switching logic fast and easy.
Cookies
When the cookie have to do with the credential of the user then you need to force it to be transmitted only with secure page. What this mean, mean that if you set a cookie with https, this cookie is NOT transmitted on non secure page, so is stay secure and a man in the middle can not steal it. The tip here is that this cookie can not be read on http pages - so you can know that the user is A, or B only on secure page.
Cart - Products
Yes this is normal : to leave the products and the cart on unsecured connection because the information is not so special. You start the https page when you be on user real data, like name, email, address etc.
Auth cookie
If you set it as secure only, then this cookies not show/read/exist on unsecured page. It is an issue if you not make it secure only.
Response.Cookies[s].Secure = true;
Few more words
What we do with secure and non secure page is that we actually split the user data in two parts. One that is secure and one that is not. So we use actually two cookies, one secure and one not secure.
The not secure cookie is for example the one that connect all the products on the cart, or maybe the history of the user (what products see) This is also that we do not actually care if some one get it because even a proxy can see from the url the user history, or what user see.
The secure cookie is the authentication, that keep some critical information for the user. So the non secure cookie is with the user everywhere on the pages, the secure is only on check out, on logged in, etc.
Related
MSDN, How To: Protect Forms Authentication in ASP.NET 2.0
Setting up SSL page only on login page
Can some hacker steal the cookie from a user and login with that name on a web site?
1) Yes, you are right.
2) Yes. You can optionally handle HTTP 403.4 code (SSL required) more gracefully, by automatically redirecting the client to the HTTPS version of the page.
As for authentication cookies, I've found this MSDN article for you. Basically, you can set up your website (and the client's browser) to only transmit authentication cookie via HTTPS. This way it won't be subject to network snooping over unencrypted channel.
Of course, this is only possible if all of your [Authorize] actions are HTTPS-only.