Ted Young radicalDESIGNS On Feb 18, 2012, at 10:54 PM, Avi Deitcher wrote:
> Yeah, that's why I really prefer that there is no direct access to files that > are supposed to be protected. All files that are protected are in > /path/to/private/files/ and nothing can get at them except express. Express > only allows access via /api/:user/:file. If /:user is allowed to get :file, > and the user is logged in and thus has access to that path, then express will > go get the file and serve it. Guess the URL all you want, it doesn't matter. Yep. Also, if you are running nginx as a reverse proxy and would like it to send the file instead of node, you can use the X-Accel-Redirect header: http://wiki.nginx.org/XSendfile I wonder if there's a way to do this, but not have nginx running as a reverse proxy? Perhaps because you also want to server websocket requests, etc? Not that node can't send files just fine for many use cases. > > On Sun, Feb 19, 2012 at 8:52 AM, Ted Young <[email protected]> wrote: > >> Provided the hash is cryptographic or at least well distributed wrt >> clustering, repeating substrings, etc, you're right: entropic security >> driven by the DoS heat death of my server as someone tries in vain to create >> a hash collision! I could probably write a fail2ban rule for that. But I'm >> now thinking again about using an on-the-fly hash with a TTL in the database >> to discourage guessing and make it obvious that these are not meant to be >> permalinks. >> >> Thanks for the good discussion! >> > > One problem with entropic security is there is no security once someone gets > the link. For example, a user has access but later has that access revoked, > etc, or someone emails the link to an unauthorized person by accident, etc. > > >> On Feb 18, 2012 10:43 AM, "Bruno Jouhier" <[email protected]> wrote: >> Idea 1: if your file is identified by a UUID (type 4, 128 bits, >> randomly generated), there is simply no way any brute force algorithm >> will be able to guess it (*). Why isn't this good enough? >> >> (*) even if entropy is only 90 bits out of 122, this gives 2^90 ~ >> 10^27 combinations. If you can test one combination per nanosecond >> (rather fast), this gives you 10^18 seconds ~ 10^13 days ~ 3 10^10 >> years to enumerate all the combinations. So, to get 1% chance of >> hitting a match, you'd have to wait on average 300 million year (or 1 >> year with 300 million computers). >> >> This is not security by obscurity, this is entropic security. >> >> On Feb 18, 2:45 am, "C. Mundi" <[email protected]> wrote: >> > This is obviously a solved problem. I don't want to reinvent the wheel. >> > >> > Imagine a digital music store. I have a set of static files which I need >> > to serve only to authenticated users. So the set of accessible files >> > depends on the user. How do I let each user get the files she is entitled >> > to and no other files? >> > >> > Bad Idea 1: security by obscurity: hide the files behind query strings >> > generated on the fly for session.user in the form of nasty looking hard to >> > guess hashes. Ugly hack and vulnerable to brute force hash collision. >> > Yuck! >> > >> > Bad Idea 2: set up an instance of node-static.Server() for each >> > authenticated session, specifically serving a directory created on the fly >> > for that session and containing symlinks to all (and only) files for which >> > session.user has privileges. The main server would redirect requests for >> > files to the ad hoc static server. Kludgus maximus! >> > >> > Good Idea: what you tell me. :) >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/nodejs?hl=en?hl=en > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
