[twitter-dev] Re: Account Verify Credentials

2009-08-07 Thread Chris Babcock

On Thu, 6 Aug 2009 12:01:14 -0400
Robert Fishel bobfis...@gmail.com wrote:

 I too thought that one should call verify credentials with Oauth. How
 are you suggesting we verify that the token is still active, another
 call to oauth_authenicate/authorize?

The oauth_authenicate and oauth_authorize calls are not rate limited.
They can't be used to hack user credentials, so they don't need to be.

Authentication is a once per session event. Once authenticated, a user
remains authenticated to your app until your own session controls
expire. This is independent of the user's Twitter session, except that
the user needs to be authenticated with Twitter in order for Twitter
to authenticate the user to your app. This happens once, at the
beginning of the user's session with your app and it is not subject to
a DoS attack on the account/verify_credentials service. 

It may be useful to verify that an authorization token has been
activated, but checking authorization before a call that will fail if
the authorization is not available is wasted bandwidth. You should
check after the call to see if the action succeeded. It's more reliable
and lower bandwidth. 

Chris Babcock



[twitter-dev] Re: Account Verify Credentials

2009-08-07 Thread Robert Fishel

Except that this case fails for calls such as statuses/friends if the
user isn't authenticated but you think he is you get a completely
valid (from one point of view) set of results back but they do not
include any protected users. Therefore a call to verify_credentials is
necessary to ensure that you are processing the correct data.

-Bob

On Thu, Aug 6, 2009 at 10:36 PM, Chris Babcockcbabc...@asciiking.com wrote:

 On Thu, 6 Aug 2009 12:01:14 -0400
 Robert Fishel bobfis...@gmail.com wrote:

 I too thought that one should call verify credentials with Oauth. How
 are you suggesting we verify that the token is still active, another
 call to oauth_authenicate/authorize?

 The oauth_authenicate and oauth_authorize calls are not rate limited.
 They can't be used to hack user credentials, so they don't need to be.

 Authentication is a once per session event. Once authenticated, a user
 remains authenticated to your app until your own session controls
 expire. This is independent of the user's Twitter session, except that
 the user needs to be authenticated with Twitter in order for Twitter
 to authenticate the user to your app. This happens once, at the
 beginning of the user's session with your app and it is not subject to
 a DoS attack on the account/verify_credentials service.

 It may be useful to verify that an authorization token has been
 activated, but checking authorization before a call that will fail if
 the authorization is not available is wasted bandwidth. You should
 check after the call to see if the action succeeded. It's more reliable
 and lower bandwidth.

 Chris Babcock




[twitter-dev] Re: Account Verify Credentials

2009-08-06 Thread Chris Babcock



On Aug 5, 10:15 pm, Jesse Stay jesses...@gmail.com wrote:
 On Wed, Aug 5, 2009 at 3:04 AM, Chris Babcock 
 cbabc...@kolonelpanic.comwrote:



  I would strongly recommend OAuth for verifying users, or at least
  making it an option, as there is a DoS attack possible against service
  providers who rely on this API for access to their app.

  Chris Babcock

 I'm not sure how OAuth helps, as the problem still exists, even with OAuth
 users.  Even with OAuth, it is still 15 requests per user per hour on
 verify_credentials.  Of course, you probably don't have to run
 verify_credentials as often with OAuth, but the problem still exists, and
 there are cases where I can see this could become an issue.

 Jesse

No, you *never* use verify_credentials with OAuth because you never
handle user passwords.

Take for example those users whose accounts are being slammed by
SpamBots. They can still log into Twitter, just not those services
that rely on verify_credentials service. Because they can still log in
on the Twitter site, they could still authorize OAuth tokens. You will
know that they have valid credentials on Twitter if the token has been
authorized when they return to your site. It's not necessary for your
app to obtain and verify the credentials directly. Your app can
completely bypass the rate limited service with its DoS potential.

Chris Babcock



[twitter-dev] Re: Account Verify Credentials

2009-08-06 Thread Robert Fishel

Chris,

I too thought that one should call verify credentials with Oauth. How
are you suggesting we verify that the token is still active, another
call to oauth_authenicate/authorize?

Thanks

-Bob

On Thu, Aug 6, 2009 at 7:51 AM, Chris Babcockcbabc...@kolonelpanic.org wrote:



 On Aug 5, 10:15 pm, Jesse Stay jesses...@gmail.com wrote:
 On Wed, Aug 5, 2009 at 3:04 AM, Chris Babcock 
 cbabc...@kolonelpanic.comwrote:



  I would strongly recommend OAuth for verifying users, or at least
  making it an option, as there is a DoS attack possible against service
  providers who rely on this API for access to their app.

  Chris Babcock

 I'm not sure how OAuth helps, as the problem still exists, even with OAuth
 users.  Even with OAuth, it is still 15 requests per user per hour on
 verify_credentials.  Of course, you probably don't have to run
 verify_credentials as often with OAuth, but the problem still exists, and
 there are cases where I can see this could become an issue.

 Jesse

 No, you *never* use verify_credentials with OAuth because you never
 handle user passwords.

 Take for example those users whose accounts are being slammed by
 SpamBots. They can still log into Twitter, just not those services
 that rely on verify_credentials service. Because they can still log in
 on the Twitter site, they could still authorize OAuth tokens. You will
 know that they have valid credentials on Twitter if the token has been
 authorized when they return to your site. It's not necessary for your
 app to obtain and verify the credentials directly. Your app can
 completely bypass the rate limited service with its DoS potential.

 Chris Babcock




[twitter-dev] Re: Account Verify Credentials

2009-08-06 Thread Jesse Stay
What Robert said.  You still need to verify.

On Thu, Aug 6, 2009 at 12:01 PM, Robert Fishel bobfis...@gmail.com wrote:


 Chris,

 I too thought that one should call verify credentials with Oauth. How
 are you suggesting we verify that the token is still active, another
 call to oauth_authenicate/authorize?

 Thanks

 -Bob

 On Thu, Aug 6, 2009 at 7:51 AM, Chris Babcockcbabc...@kolonelpanic.org
 wrote:
 
 
 
  On Aug 5, 10:15 pm, Jesse Stay jesses...@gmail.com wrote:
  On Wed, Aug 5, 2009 at 3:04 AM, Chris Babcock 
 cbabc...@kolonelpanic.comwrote:
 
 
 
   I would strongly recommend OAuth for verifying users, or at least
   making it an option, as there is a DoS attack possible against service
   providers who rely on this API for access to their app.
 
   Chris Babcock
 
  I'm not sure how OAuth helps, as the problem still exists, even with
 OAuth
  users.  Even with OAuth, it is still 15 requests per user per hour on
  verify_credentials.  Of course, you probably don't have to run
  verify_credentials as often with OAuth, but the problem still exists,
 and
  there are cases where I can see this could become an issue.
 
  Jesse
 
  No, you *never* use verify_credentials with OAuth because you never
  handle user passwords.
 
  Take for example those users whose accounts are being slammed by
  SpamBots. They can still log into Twitter, just not those services
  that rely on verify_credentials service. Because they can still log in
  on the Twitter site, they could still authorize OAuth tokens. You will
  know that they have valid credentials on Twitter if the token has been
  authorized when they return to your site. It's not necessary for your
  app to obtain and verify the credentials directly. Your app can
  completely bypass the rate limited service with its DoS potential.
 
  Chris Babcock
 
 



[twitter-dev] Re: Account Verify Credentials

2009-08-05 Thread Chris Babcock
On Tue, 4 Aug 2009 16:40:27 -0400
Bob Fishel b...@bobforthejob.com wrote:


 On Tue, Aug 4, 2009 at 1:45 AM, Bob Fishelb...@bobforthejob.com
 wrote:
  From the api documentation:
 
  Because this method can be a vector for a brute force dictionary
  attack to determine a user's password, it is limited to 15 requests
  per 60 minute period (starting from your first request).
 
  Is this per user?
 
  ie: if my server queries user A and gets credentials verified ok
  after 14 other users verify am I locked out or is it just after 15
  tries for the same user? The former would seem illogical but I just
  want to make sure...
 
  Thanks,
 
  Bob
 
 
 I hate to bump this as it were but does anyone have any insight?
 
 Thanks,
 
 Bob
 

The actual behavior is 15 requests, regardless of success, per username.
I tested it by using curl with one account until I got an error then I
tried it with a different account - successfully - and retried the
first account to make sure the block was still in place. I also changed
the source IP address in curl to verify that access is not tracked by
IP Address. 

I would strongly recommend OAuth for verifying users, or at least
making it an option, as there is a DoS attack possible against service
providers who rely on this API for access to their app.

Chris Babcock



signature.asc
Description: PGP signature


[twitter-dev] Re: Account Verify Credentials

2009-08-05 Thread Chris Babcock
On Tue, 4 Aug 2009 16:40:27 -0400
Bob Fishel b...@bobforthejob.com wrote:


 On Tue, Aug 4, 2009 at 1:45 AM, Bob Fishelb...@bobforthejob.com
 wrote:
  From the api documentation:
 
  Because this method can be a vector for a brute force dictionary
  attack to determine a user's password, it is limited to 15 requests
  per 60 minute period (starting from your first request).
 
  Is this per user?
 
  ie: if my server queries user A and gets credentials verified ok
  after 14 other users verify am I locked out or is it just after 15
  tries for the same user? The former would seem illogical but I just
  want to make sure...
 
  Thanks,
 
  Bob
 
 
 I hate to bump this as it were but does anyone have any insight?
 
 Thanks,
 
 Bob
 

The actual behavior is 15 requests, regardless of success, per username.
I tested it by using curl with one account until I got an error then I
tried it with a different account - successfully - and retried the
first account to make sure the block was still in place. I also changed
the source IP address in curl to verify that access is not tracked by
IP Address. 

I would strongly recommend OAuth for verifying users, or at least
making it an option, as there is a DoS attack possible against service
providers who rely on this API for access to their app.

Chris Babcock



signature.asc
Description: PGP signature


[twitter-dev] Re: Account Verify Credentials

2009-08-05 Thread Jesse Stay
On Wed, Aug 5, 2009 at 3:04 AM, Chris Babcock cbabc...@kolonelpanic.comwrote:


 I would strongly recommend OAuth for verifying users, or at least
 making it an option, as there is a DoS attack possible against service
 providers who rely on this API for access to their app.

 Chris Babcock


I'm not sure how OAuth helps, as the problem still exists, even with OAuth
users.  Even with OAuth, it is still 15 requests per user per hour on
verify_credentials.  Of course, you probably don't have to run
verify_credentials as often with OAuth, but the problem still exists, and
there are cases where I can see this could become an issue.

Jesse


[twitter-dev] Re: Account Verify Credentials

2009-08-04 Thread Bob Fishel

I hate to bump this as it were but does anyone have any insight?

Thanks,

Bob

On Tue, Aug 4, 2009 at 1:45 AM, Bob Fishelb...@bobforthejob.com wrote:
 From the api documentation:

 Because this method can be a vector for a brute force dictionary
 attack to determine a user's password, it is limited to 15 requests
 per 60 minute period (starting from your first request).

 Is this per user?

 ie: if my server queries user A and gets credentials verified ok after
 14 other users verify am I locked out or is it just after 15 tries for
 the same user? The former would seem illogical but I just want to make
 sure...

 Thanks,

 Bob