That is interesting. I don't recall who it was who said that the brilliance of capitalism over every other system is that every other system tries to make humans into what they ideally want to be; capitalism accepts humans with all of their failings and builds a system around them. But leaving political philosophy aside...
Your argument appears to be, "look, if people didn't share their auth credentials, then traditional auth/auth would be great. But people *do* share, let's accept that, and build a system that does the best it can around that, by limiting the damage done by sharing, and possibly even making it something of a virtue." I like the philosophical approach, but can it be applied in user space? The valid problems you are discussing are primarily on user interaction - someone shares their Facebook or Twitter credentials, e.g. - and not in the systems space. Yet in the user space, users will not willingly agree to moving from one set of credentials on their system (e.g. Facebook login/pass) to having multiple, each with its own credentials (Facebook login/pass for viewing, another for posting, another for changing privacy settings, etc.). Humans want an interaction similar to the real world, "I am here, you recognize me, not let me do everything I am allowed to do!" There is a reason cars have only two kinds of keys - the master and the valet - even though we could make valid arguments for 3, 4 or 5 different "capability" keys. On the other hand, in the systems space, the problem of sharing is much less of an issue. What does capabilities buy me here? Last, in either space, Adam may not need to go to the server to grant access to Eve, but he still needs to go to the server to create extra credentials for Eve, and if he ever wants to revoke them, he has to go to the server. What has Adam gained over traditional auth/auth, when he could tell Eve, "sign up for an account at myfooserviceisweird.com," and then just grants her access? On Feb 24, 10:55 am, David Bruant <[email protected]> wrote: > > 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 > credentialshttp://www.nytimes.com/2012/01/18/us/teenagers-sharing-passwords-as-s... > 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. > > > 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. > > I get the "no need to change anything on the server part," but IMHO the > > > > > > > > > security issues outweigh. Now, if you combined them, that might be > > interesting from a security perspective, but that begins to sound a lot > > like Kerberos. -- 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
