On Fri, Feb 24, 2012 at 3:55 AM, David Bruant <[email protected]> wrote:
> On Friday, February 24, 2012 1:40:54 AM UTC+1, deitch wrote: >> >> It seems like that is the only thing. Essentially, these are two >> completely different philosophies: >> >> 1- Authorization: each of us has a unique key to authenticate, and >> authorization is controlled server-side. For Adam to give Eve access to >> something, John must do so on the server, and all he tells Eve is "go >> ahead, you can do it now." >> 2- Capabilities: a unique key gives privilege rights for an action, and >> identifies the right to do that action, rather than the actor. You can >> share capabilities server-less. >> >> The problems I have with scenario 2 are: >> a- auditing (this is security, right?) is impossible. If Adam shares a >> key with Emily, we no longer know if it is Adam or Emily. >> > When you issue a login/password pair for your user, how can you be sure > that the person who connected is the one who you shared the login/password > with? > You can't. > Hence the problem when a server gets hacked and login/password pairs are > revealed. > Hence the problem that can come with teenagers sharing their credentials > http://www.nytimes.com/2012/01/18/us/teenagers-sharing-passwords-as-show-of-affection.html?_r=1 > With regard to sharing, capabilities are as vulnerable as any form of > authentication to sharing. > People sharing their login/password is a reality and has never prevented > an audit. It's just something to be aware of when auditing. > > On the positive side, with capabilities, it is possible to share with > finer granulairty than access to your entire account. > Perhaps even nicer, it's possible to attenuate and revoke. When sharing a capability with someone you don't have to share it outright (like with an identity). You create a new capability that you hand out that uses your handle to the capability you want to share. In the process you can arbitrarily limit the capability you're handing out by rejecting certain actions that would otherwise be acceptable through the existing capability. And when you want to unshare some capability with a user you don't have to change your password or even get a new capability from the source -- you just disable the capability you created and handed out (e.g. reject every action). > >> b- behaviour is looser. Adam and Eve now share keys regularly, and may >> even share them outside >> > They share on the basis that they trust one another. There is no problem > from a security standpoint. > If the security of your system relies on people not sharing anything ever, > your system is already compromised. > Exactly, and in a more fundamental way -- they'll share identity (ALL of their capabilities) as a proxy for sharing specific capabilities. There are other advantages to capabilities (e.g. the "confused deputy" problem [1]). It's certainly worth reading up on -- even if you don't know of it you'll almost certainly reinvent it when trying to scale your auth. Then you'll think *this can't possibly be secure -- it's too simple, *and you'll be tempted to layer on some other gnarly form(s) of access control, but this will be a mistake. [1] http://en.wikipedia.org/wiki/Confused_deputy_problem -- 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
