Let us just make it clear, if it still wasn’t. Before an attacker has access to your local storage, it means the attacker already has access to the session of your users, first and foremost. Let that sink in first
It’s exactly the same for a cookie - js can access that value. A difference with the cookie though, is that the value of the cookie is sent back and forth with every http request, where as the value stored in local storage is not. And like I said before, we can’t use an httpOnly cookie, because Meteor needs to be able to read the value client side.
So the solution is to use multi-factor authentication. It should be inbuilt to all websites these days. Pick two:
- something they know,
- something they have, or
- something they are.
As long as the 2fa does not store the token locally “to remember” the device or else it is also vulnerable if the client is compromised
I have been using REDIS for the authentication part of my app in meteor. And in serverside cookies are there for load balancers to work properly. Check this package this is the one I have been using for authentication and token storage and so on.
Not sure which article you are referring to, as I cited a few. Some advantages of cookies are:
httpOnlysetting. See, for example, https://blog.codinghorror.com/protecting-your-cookies-httponly/ (“HttpOnly cookies don’t make you immune from XSS cookie theft, but they raise the bar considerably.”)
- Edited to add: expiration
- The argument that “no XSS is possible on my site” is both besides the point and utterly wrong. (I am not attributing this argument to you, just enumerating)
- The argument that “it’s all the same once the client is compromised” is also wrong, for the numbered reasons above.
- It seems to me that some people are arguing against the claim “Cookies are perfect”, but this is a straw man. The claim is: they are superior.
- localStorage is simply not intended to store sensitive information, but cookies are (at least, by comparison). Why not “honor” the intention?
- My proximate/initial motive in this thread is regarding the stance taken up top, basically opposing the customer, instead of supporting. I mean, your chances of convincing the auditor are sub-zero, and also, maybe it should give us pause to hear what paid specialists are saying, and do we want Meteor to appeal to serious, corporate customers – or not? Even if the concern didn’t make sense (it does), accommodation seems like a productive response.
@captainn If the cookie is marked by the server with httpOnly, it’s not available via
document.cookies. See https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Creating_cookies
A cookie is sent on every HTTP request, so it is available on the server side. To use this pattern for Meteor, the login must be treated different than now, because this is done entirely using web sockets and the login method.
Does the definition of “anyone with local access” include XSS-attackers?
That’s right. What I meant was that Meteor can’t just use a monkey patch and switch to using
httpOnly cookies in place of another client readable method (local storage or secure cookies). The client side app needs access to the auth token to send it with requests over DDP.
I wonder if a sort of half-duplex model could be constructed from various parts though. We really only require DDP requests to contain the auth token, not receipts. There are already tools to set up cookies for SSR (
staringatlights:fast-render) and others to convert methods to REST. If Meteor was modified a bit, it could probably be set up to receive http requests (method/subscription requests) which would attach
httpOnly cookie auth token, and then respond through a DDP connection.
What? Who is “you”? Browser security prevents it, but otherwise it doesn’t? [Parse Error]
If local storage has only been used due to Galaxy then we may put this on the current feature request list for Tiny, correct?
Hi all, thank you everyone for some robust discussion.
It would be amazing if we could get a feature request to address this - not sure what or where to request this though… @jkuester - is this something you could setup? (and throw a link to the Feature Request here?)
Is it needed to send the cookie auth on every method/sub calls? It might be possible that only the initial connection that will authenticate the cookie and then succeeding calls will be an “authenticated” ddp. Or are we talking about the same thing?
Possibly - I haven’t looked at the code that controls DDP. I’m not actually certain that the token is even transferred with every request. It actually would make sense not to. But there are recovery scenarios where I think the token would be needed, such as lost and recovered connections, changing IPs, etc.
If it’s not needed for every request, maybe just the handshake (however that works) could be done over HTTP with the
@nickg123, feature requests for Meteor can be made here:
Created a new request:
Looking around, there are already a few feature requests similar that could be used for reference:
Hey @nickg123 the latest topics in this forum are feature requests from Tiny regarding desired Meteor and Galaxy Features:
I already posted in the Galaxy topic and linked this one
I’d like to emphasize by the way, that until we have a stable http auth system, we still have a great cookies implementation already:
which is also used in
ostrio:files and they are constantly improving, especially the cordova-related headaches are currently tackled.