[security] Unsubscribe

Tue Feb 10 20:02:18 UTC 2009

Help
Unsubscribe

VON Reporting Specialist

Phone:  802-865-4814, ext. 209

Fax:  802-865-9613

-----Original Message-----
From: security-bounces at openid.net [mailto:security-bounces at openid.net]
On Behalf Of security-request at openid.net
Sent: Tuesday, February 10, 2009 3:00 PM
To: security at openid.net
Subject: security Digest, Vol 18, Issue 5

Send security mailing list submissions to
	security at openid.net

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
	security-request at openid.net

You can reach the person managing the list at
	security-owner at openid.net

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 <sysadmin at shadowsinthegarden.com>
Subject: Re: [security] how secure is openid? advise pls..
To: Balasubramanian G <mccbala at gmail.com>
Cc: security at openid.net
Message-ID: <f06110401c5b75ad0073c@[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 <sysadmin at shadowsinthegarden.com>
Subject: Re: [security] how secure is openid? advise pls..
To: Dan Lyke <danlyke at flutterby.com>
Cc: security at openid.net
Message-ID: <f06110401c5b764313b5e@[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
security at openid.net
http://openid.net/mailman/listinfo/security

End of security Digest, Vol 18, Issue 5
***************************************