Help Unsubscribe VON Reporting Specialist
Phone: 802-865-4814, ext. 209 Fax: 802-865-9613 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, February 10, 2009 3:00 PM To: [email protected] Subject: security Digest, Vol 18, Issue 5 Send security mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://openid.net/mailman/listinfo/security or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of security digest..." Today's Topics: 1. Re: how secure is openid? advise pls.. (SitG Admin) 2. Re: how secure is openid? advise pls.. (SitG Admin) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Feb 2009 10:00:18 -0700 From: SitG Admin <[email protected]> Subject: Re: [security] how secure is openid? advise pls.. To: Balasubramanian G <[email protected]> Cc: [email protected] Message-ID: <f06110401c5b75ad00...@[192.168.0.2]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" >I need to be on a watch of what people do. So can i atleast restrict >them to use only one id with which they login the first time? >because i have to calculate their usage and all and fix them >specific download quotas. so i shud make sure that the user doesn't >use another openid to login and continue using the website. pls >advise.. Um . . . no, OpenID (and this applies to any authentication system) is not the answer. There is NO authentication system (and don't trust anyone in the world who tells you otherwise) that can guarantee you, over the anonymity of the 'net, a given user is not someone who has dealt with you before. Simply impossible. Individuals (important distinction from users, here - an individual is any person at the other end of a keyboard, users are how you know them at your site) cannot be FORCED to use the same credentials consistently. You *might*, conceivably, receive an offer from some mercenary team that would meet (on your behalf) potential "clients" (wannabe "users"), babysit them 24/7, and give you a call every time the individual was about to log in so you could confirm their username - but this is an exception, not the rule, and in any case unfeasible for your non-profitable music site ;) Unless you're the RIAA . . . but even they haven't gone that far. Yet ;) You can limit your popularity with certain OpenID's, in an attempt to combat such tactics as "subdomain1.user.com, subdomain2.user.com, subdomain3.user.com", but what do you do if you see "profile.yahoo.com/D1105508B89AFBBF162C4B88966"? (Note: probably not a valid URI for Yahoo, just a quick example.) Does this mean that users are availing themselves of an ability to present a different URI to an OP on each authentication, to avoid tracking? Perhaps it simply means that the user has created more than one Yahoo account? (Which, by the way, are free.) How do you propose to keep the user from trying "another OpenID" when that OpenID is the very method by which you would identify users? You can track their IP address (this could be part of an authentication system, complementing OpenID), banning numbers and then entire blocks with excessive use (the exact definition of "excessive" being up to you), but some of them will just go through free proxies. This is self-limiting; if more than one person uses a proxy, you just catch it faster. If you do go that route, automate it, because new proxies are always becoming available (and old ones, disappearing), and you don't want to waste your time on that endless task. I don't recommend it, though; you can go a long way with such countermeasures, and STILL have problems. You can hope to keep the costs down to manageable levels, at best. But users who want to "cheat" will still do so; *they* can outthink *you* - not all of them, and not all of the time, but a few of them will always be slipping through. The strategy I recommend is *rewarding* users for staying with a single OpenID: make the benefits outweigh whatever short-term gain they might receive, so users won't *want* to cheat that way. This *would* encourage people to use the same OpenID for logging in, no matter where they are. Find out which OP's (if any) offer a unique password for logging in to predefined sites (OSP: one-site-password), and recommend them to users, so the OP doesn't became a gateway to all that user's *other* sites if they log into your site from a public terminal. -Shade ------------------------------ Message: 2 Date: Tue, 10 Feb 2009 10:49:50 -0700 From: SitG Admin <[email protected]> Subject: Re: [security] how secure is openid? advise pls.. To: Dan Lyke <[email protected]> Cc: [email protected] Message-ID: <f06110401c5b764313...@[192.168.0.2]> Content-Type: text/plain; charset="us-ascii" ; format="flowed" >> The question then becomes - how do you know you can trust a given OP? > >Which, when compared to a traditional password situation, becomes "how >do you know you can trust a given user". It's a bit more complicated than that, actually. >> Or, if those assertion are *not* present, inform the user that their >> OP has vouched for them but the level of security is not sufficient >> to permit full services. > >Or let them make that call. > >I've had at least one bank Banks are an excellent example of exactly why RP's *do* need to make these calls. I haven't had time to write a reply properly addressing these points, but Andrew has touched on most of them, so I'll simply run a short scenario by you: Your bank lets you transfer money by logging into their website. One day, their system recognizes your password and logs you in, whereupon you promptly transfer most of your money to another account. A few days later, you walk into their physical building and raise hell about it. What happens next? 1) They tell you that you can't have your cake and eat it too. 2) They acknowledge the possibility of fraud but tell you that YOU were responsible for safeguarding your password, and the password was obviously known, so it's YOUR fault the money is gone and THEY are not liable for its loss. That's what it's all about: liability. If *their* security is compromised and someone steals all the user's passwords, it's THEIR fault, and heads will roll (probably) . . . but when accusations of theft *do* occur (and they will), are they going to keep the user waiting while investigations are pursued, which may not even unearth anything? No; banks provide security of mind, the knowledge that we have money and that our losses are covered. They may try to recover those losses (because our losses are their losses), but they may write it off as more expenditure than it's worth. Spyware is prevalent, the user may have had some. End of story. Or was #1 the *real* story? Was the user really trying to have their cake and eat it too, double their money by transferring it to another account (for withdrawal) and then claiming that the money was stolen? Introduce a 3rd party (the OP) and users have someone else to blame - and fraud is suddenly looking much easier. That doesn't mean it will *be* easier, but it *does* suggest that more people will be *trying* - and losses go up. And these are just *monetary* losses! Not all breaches are a simple matter of budgeting for future compensation. Compromising a spy's cover (revealing their mission/identity) could literally be life and death. A company could go down if their (trade) secrets were to fall into the wrong hands. We're basically looking at two or three interested parties here: 1) the insurance company that provides coverage against fraud 2) the user who wants ready access to services 3) the RP that needs to keep some data out of unprivileged hands Let the user make that call, unilaterally? Unacceptable. And remember, this isn't some case where the user can say "You *must* accept it, one of the tenets of OpenID is that you must permit me to choose my own OP." - frankly, I don't give a flying *duck* what the authentication system's philosophical ideals are, I'm not under an external obligation to provide services to that user under any terms the user dictates. We have a contract. It works both ways. In fact, one might say that *because* my contract obliges me to provide services *to that user and ONLY to that user*, I am duty-bound to do my utmost, by any and all measures I see fit, to ensure that noone else can pose as that user! -Shade ------------------------------ _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security End of security Digest, Vol 18, Issue 5 *************************************** _______________________________________________ security mailing list [email protected] http://openid.net/mailman/listinfo/security
