I am using Backbone.js and it communicates with a stateless rest API. Some calls require authentication, through HTTP basic.
What I don't understand is, somehow I have to authenticate each request, how could I do this securely? My first thought was to have a cookie, store the username and password but this would be vulnerable?
Can this be done securely?
There are two themes to this question. One is about security and one seems to be about REST rules.
The way to do authentication securely, is to pass that data through an SSL connection. It's the only way to securely transfer data over the wire.
With regards to sending authentication using basic auth over each request (REST), not many people I know do this in reality.
There's always a big long discussion on how much security is enough security and it really depends on your application and what the purpose is. I know this isn't the definitive answer you might be looking for but I'll just give you my take and how I'm going about dealing with the issues you mention.
With RESTful apps, the story is one should authenticate each request but in real practice I find this is more a "guide" than a hard rule. Rare is the fully RESTful application that follows all the rules. I use an encrypted cookie to store the user session data with a standard authentication flow that happens once and expires in a week. Data transfers happen through SSL to prevent MITM attacks and a modified Backbone sync sends a CSRF token along with each POST, PUT, DELETE to prevent cross site request forgeries. Probably "good enough" for the social app that I am working on. Maybe not if you're doing bank wire transfers and stuff. Hope this sort of gives you a point of reference in judging what you might want to do.
Is https://github.com/fiznool/backbone.basicauth something you'd find useful?
This plugin enables access to remote resources which are protected by HTTP Basic Authentication through your Backbone Models and Collections.
How does it work?
A resource protected with HTTP Basic Authentication requires the following HTTP header to be set on every request:
Authorization: Basic
The access token is formed by taking the username and password, concatenating together with a : separator and encoding into Base64.
This plugin handles the Base64 encoding and automatically sets the Authorization header on every request which uses Backbone.sync.
Related
I was reading articles about `JWT` security in SPA apps, but got confused about it being prone to many types of attacks, and unintuitively hard to grasp and set up.
As far as I am aware, this whole thing with the user-friendly security is about a user staying logged in even after a browser restart, and about still being protected from CSRF attacks.
I read some crazy approaches using localStorage, cookies, or in-memory values, and about setting some flags like httpOnly on cookies, and some headers in a browser, while being vulnerable to stuff like XSS or CSRF attacks if not set properly.
So, my question is if the following security scheme would work?:
store JWT token anywhere on user's device (localStorage, cookies, whatever,...) (as a public information, readable by anyone)
backend would return an anti-CSRF header on each request
app would store and refresh the header value in a memory every time and consecutively send it to prove being the originally logged-in user
an attacker could eventually get the JWT and/or try some XSS or CSRF, but it would be useless, because he wouldn't know the anti-CSRF header value
(Note that with such an approach I basically consider the JWT token to represent authentication, and the CSRF header to represent authorization.)
the answer to your question is no.
If i manage to do a XSS on your site, i will have access to everything that your javascript has access to and that includes both the CSRF token, and the JWT. Its your javascript that will run my malicious javascript, which means i have all access to everything you have.
JWT tokens as session trackers are very bad from many perspectives. Cookies have been around since Netscape created them back in the late 90s. They have been enhanced with several security features like HttpOnly flags etc which JWTs just don't have.
JWTs are good if you have server to server stateless communication, since you can include claims, which add extra information so that the server doesn't need to do extra calls to for instance an issuers /userInfo endpoint.
Server to server communication is also usually done in secured networks so the risk for token stealing or MITMs are reduced.
Security is hard, much harder than many think, there is no one "easy solution" you need to protect your sites from multiple different attacks, and combination of these.
You should NEVER build your own custom solutions, because there is always people smarter that can break custom solutions.
And you should constantly consult the OWASP Cheat Sheet series which tries to gather everything you should think about when building modern web pages.
I am thinking of creating a web api application using .Net. Here is what I am thinking of how to implement this.
The application will be serving clients who's credentials I will create separately.
These credentials will be encrypted using my own private key.
I will provide them this encrypted text.
They will use this encrypted text in the Authorization header.
On the server I will implement an AuthorizationFilterAttribute.
In here I will decrypt and validate the user.
And allow it to go to the resource.
I honestly do not understand this topic in depth. Therefore I was wondering if my approach will work.
In my tests I have seen that all requests do hit the AuthorizationFilterAttribute which means I will have the chance to check credentials on every request.
Bearer Token might not work as for that I will need (my understanding) at least 2 requests one to get token and next one to get actual resource. Please guide.
Thanks
I would like to secure a .NET Web API service. I will be using SSL, but I also need to restrict the Web API calls that each user can call depending on the user's permissions.
From what I've read, REST/HTTP is supposed to be stateless, so technically you shouldn't be able to maintain any session state, but there are some ways around that.
One is to use basic authentication. The credentials are sent with every request. While this may be okay security-wise because they're being transmitted over SSL anyway, it really isn't practical given that it would require a lot of overhead to re-authenticate against the database every time. (A possibility might be to cache them in memory, but I doubt that's the best way.)
Another could be to use an HMAC (example implementation) to control access to API calls. There is a comment in this article that says:
Just to be clear to people that are implementing this on their HTTPS services: YOU DON'T NEED TO IMPLEMENT HMAC ON SSL!!! It's a waste of time and waste of complexity for absolutely no reason. DON'T DO IT. Use Basic Auth and be done with it.
I don't agree with this for the reasons mentioned above (it is more practical to authenticate once and control using HMAC than authenticate every time).
Is it a good and effective practice to use an HMAC to provide security to Web API calls when working over SSL, or are there any points that I am missing?
The answer depends on how much you care about security.
What is this API being used for? If security is a big concern, Basic Authentication is NOT a sufficiently good choice -- even if you're using SSL.
Even if you're using SSL, an attacker who can control or get access to your initial request can pretend to be the desired HTTPS web service, and intercept your traffic easily (then get a hold of your API credentials).
A much better solution is to do several things:
Use an API key and secret.
Generate a unique ID with each request.
Generate a timestamp with each request.
Encrypt the body of your request against your API key secret.
Put the encrypted output into the HTTP_AUTHORIZATION header in the form: API_KEY_ID:<encrypted_output>
On the server side, decrypt the payload.
Compare the timestamp -- if the request was sent more than a second before -- drop it (this prevents timing attacks).
Compare the unique id -- if this request was already executed -- drop it (this prevents replay attacks).
The above strategies make it impossible for attackers to gain access to your API credentials, even if they are able to successfully man-in-the-middle your API calls.
I want to create a authorization mechanism for an application based on WebAPI and AngularJs.
I've seen some articles, which use BasicHttpAuthentication, but i really don't like the whole idea of sending username, and password on every request. The more it doesn't fit for me is because i want to use OpenId authentication, where you don't have username/password pair.
I'm thinking about a solution, but I don't really know how to implement it. The concept is that user is authenticated as in an usual Web application - posts a form with user / password or selects an OpenId provider. If the user is authenticated succesfully, it is placed in a static object, which stores the User object for a certain ammount of time. Next a usertoken is generated and passed to the Client Application. The client passes the token on each request to the server, if the user exists in the above mentioned static object with the appropriate authentication token it is authorized to get the data.
Firstly - Do you think this is a good approach to the problem?
Secondly - How should I pass the authentication token, WITHOUT using cookies? I guess it should sit in the request headers, like in BasicHttpAuthentication but, I really dont' know how to handle it.
BasicHttpAuthentication
I'm with you on feeling dirty about caching the username and password on the client and forever transferring it with every request. Another aspect of Basic authentication that might work against you is the lack of sign-off. Other than changing the password, you can't "invalidate" a basic authentication session. Tokens on the other hand, will typically offer an expiration date, and if you want server-side invalidation you can check the issue date and say "any tokens older than issue date xyz are invalid".
Server State
You mention "If the user is authenticated successfully, it is placed in a static object". But this is independent of the token? This sounds like you're wanting to implement server state management of authentication sessions, but this isn't strictly necessary. The token itself should be sufficient for user authentication, managing server state is another potential obstacle. Server state can become difficult to manage when you factor app-pool recycles or web-farm environments (what if you want two services to share the same authentication token, but not require communication with a central "authentication server" for storing the state / session?)
Passing Authentication Token
Headers is definitely a good place for it. Really, where else is there? Cookies, Headers, Message. Other than a browser client, cookies don't make a lot of sense, and including it in the message can muddy your message formatting a bit, so headers is the only remaining option that makes much sense in my view.
Client Implementation
You've not specified, but I suspect you're interested in calling the service from .NET? In which case System.Net.Http.HttpClient could be your friend. In particular, the DefaultRequestHeaders collection. You can use this to add a custom header to store your authentication token.
Server Implementation
When researching ASP.NET authentication recently, I learned a lot about customisation by examining the Mixed Authentication Disposition ASP.NET Module (MADAM). I wasn't interested in using MADAM as-is, but learning about it from that article and examining the source code gave me a lot of ideas of how I could insert my own authentication module into the web stack.
Is there any way (apart from HTTP authentication, which I gather is inherently insecure over the Internet?) for a "real life" website to handle logins and authentication rather than the traditional way, using session cookies?
HTTP digest authentication (which is quite a different beast from HTTP basic authentication) is quite secure over straight HTTP, and not at all difficult to implement on the server. Nothing is sent over the wire that could reveal what the password is, just information that allows the client to demonstrate to the server that they have the correct password.
If you want a decent explanation of how to implement HTTP digest authentication in your application, Paul James has an excellent article on it.
The only real problem with HTTP authentication is in the browsers themselves: the UI is terrible, but that can be overcome with some Javascript.
Addendum: This answer is almost a decade old. These days, you should really be using HTTPS regardless of any other considerations.
HTTP basic authentication is perfectly safe when used with a SSL (https://) website since all HTTP traffic including the credentials will be encrypted. One subjective drawback though is when using this method your users will need to interact with their browser's authentication popup in order to log in to your site.
To be clear, the only REAL way to do this is through HTTPS.
But, since I assume this is not an option, and I also assume you are looking for a "fully managed login" system, I continue:
Other than HTTPS it is possible to use JavaScript to do secure hashing of passwords on the client side, to prevent revealing plain text passwords over-the-wire, but this is only a half-solution.
The problems with this approach are:
A replay attack is still a viable option.
Only users with JavaScript enabled would be able to auth in this way.
Another approach is a more complicated challenge / response mechanism:
Send a "Challenge" along with the login page.
Calculate the hash of the Password + Challenge client side.
Submit the login.
Calculate the hash of the Password + Challenge (which MUST NOT be trusted in the page request) on the server side, and compare.
And the problems with that:
Only users with JavaScript enabled would be able to auth in this way.
The PLAINTEXT password must be stored on the server to validate the challenge response, and must be encrypted on disk or otherwise protected.
Now, to be fair, problem #2 is not as big of a danger as it sounds. In fact when you instead use HASH authentication, the hash itself is raised to the level of "key".
At this point it is fairly secure to use a cookie to store a randomly generated login ReferrenceID, similar to their session ID, but the server may want to encrypt using the referring IP as part of the IV or KEY to prevent other users from Hijacking the ReferrenceID.
Anyways, I hope that provides a little bit of direction in the way of your design.
HTTP authentication is not insecure when using HTTPs.
Firstly, HTTP Auth is secure over SSL other than the fact that you can't implement a true "Logout" functionality. User need to close their browser, which is pretty bad.
Secondly, It you need to use HTTPS in all cases to make it secure, after that you got Basic Auth similar stuff such as "Digest" and "NTLM Auth".
When you're using https, you can also install a certificate in your client's browser and verify that. myopenid offers this for their OpenID accounts. I have one and it works really well (from the client-side point of view).
Using SSL for encryption in combination with HttpOnly Cookies to help prevent XSS is your best bet for using cookies. I'm not going to say it is bullet-proof, though.