Sam Roberts schreef op 03-11-14 om 17:55:
On Mon, Nov 3, 2014 at 6:58 AM, Tim Kuijsten <[email protected]> wrote:
Matt schreef op 02-11-14 om 22:01:
Having said that, it's not a terrible idea to implement this kind of
thing, it just seems like you may be over-thinking it. It's far more
important to get the basics of security right in your application, and
most people don't spend nearly enough time on that.
Tim, is your server storing passwords in plain text? If so, that's
probably your biggest security problem.
Hi Sam, yes, but I'll use a file that only the superuser can read. The
privileged process reads this file before it chroots and drops
privileges itself. It's completely apart from the unprivileged child.
Ofcours the unprivileged child starts as a superuser as well, but drops
privileges before it starts listening to the network [1].
And how are you dropping privileges in your child? If the child can
get the privileges back, you have separation of responsibility, but
not separation of privileges.
I've written a little chroot helper to do this securely, though I would
appreciate some peer review [2].
And in terms of future-proofing your architecture, you might consider
implementing user-authentication as
an arbitrary separate process, not the parent, to give you the ability
to use different authentication schemes.
This is a good one, ideally I switch to public key auth. I tried to
built my own with the node tls lib but I'm not confident enough this
would be secure. If gryphon [3] wasn't built on http this would have
been a good contender, for now I stick with shared secrets (bcrypt).
Have you considered OAUTH, so that passwords don't flow through your
server at all?
Given the controversy around oauth2 [4] I haven't looked deep into it.
From a distance it looked a bit complex. I really liked the BrowserID
proposal [5], although this one is centered around the browser. Maybe
plain x509 certs will do. As you can see I still haven't made up my
mind. Maybe I have to give the tls lib another try someday (maybe if
LibreSSL's libtls, formerly known as ressl [6], makes it into nodejs?).
-Tim
[1]
https://github.com/Netsend/mastersync/blob/privsep/lib/preauth_exec.js#L126-L138
[2] https://www.npmjs.org/package/chroot
[3] https://github.com/seanmonstar/gryphon
[4] https://en.wikipedia.org/wiki/OAuth#Controversy
[5] https://github.com/mozilla/id-specs/blob/prod/browserid/index.md
[6] http://www.tedunangst.com/flak/post/goreSSL
--
Job board: http://jobs.nodejs.org/
New group rules:
https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules:
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/nodejs/5457D0B5.8030903%40netsend.nl.
For more options, visit https://groups.google.com/d/optout.
