Hi Doug,
Is there a timescale for rolling back / making the change to the new
scheme?
We're just putting the finishing touches to moving to OAuth and we're
experiencing the issue when using verify_credentials to get the users
basic details once we've got the token back from the authentication
process. We're experiencing the issue when:
1. Testing our login and authentication processes
2. When users login and logout of our application frequently
A heads up on when these changes will be made would be useful. Thanks,
Bob
On Jul 29, 6:37 pm, Grant Emsley wrote:
> Locked out of authenticated resources for that account, or will that
> IP not be able to login to any account?
>
> On Jul 29, 1:14 pm, Doug Williams wrote:
>
> > Ray,For clarity, we will roll back the current restriction of 15 calls per
> > user per hour to account/verify_credentials, and implement the proposed
> > scheme:
>
> > > ... we will limit the total number of unsuccessful
> > > attempts to access authenticated resources to 15 an hour per user per IP
> > > address. If a single IP address makes 15 attempts to access a
> > > protected resource unsuccessfully for a given user (as indicated by an
> > HTTP 401),
> > > then the user will be locked out of authenticated resources from that
> > > IP address for 1 hour.
>
> > Thanks,
> > Doug
>
> > On Wed, Jul 29, 2009 at 9:51 AM, Ray wrote:
>
> > > Doug,
>
> > > I'm in a similar situation as that voiced by TinBlue. This change has
> > > affected our iPhone App. We also want to encourage you to rollback
> > > this change ASAP.
>
> > > When you say "This approach is what we are going to take.", do you
> > > mean rolling back the fix so as not to affect multiple, successful,
> > > authorized logins? I'm hopeful that "this approach" means that our
> > > apps will not be affected yet again by changing to a new auth
> > > approach.
>
> > > I appreciate you all keeping this thread informed.
>
> > > Ray
>
> > > On Jul 27, 11:23 am, Doug Williams wrote:
> > > > Thanks to everyone who has contributed feedback. This approach is what
> > > > we
> > > > are going to take.
> > > > Alex will be making this change shortly. I will update this thread when
> > > > there is timeframe to share.
>
> > > > Thanks,
> > > > Doug
>
> > > > On Mon, Jul 27, 2009 at 7:52 AM, TinBlue wrote:
>
> > > > > What is happening?
>
> > > > > This rollback is taking far too long for something that has affected a
> > > > > lot of people!
>
> > > > > On Jul 25, 2:32 pm, Dewald Pretorius wrote:
> > > > > > Doug,
>
> > > > > > I would prefer to adopt OAuth instead of writing code for Basic
> > > > > > Auth.
>
> > > > > > So, you guys need to move OAuth out of public beta into full
> > > > > > production sooner rather than later. :-)
>
> > > > > > I manage 100,000+ Twitter accounts, and I simply cannot take on the
> > > > > > support workload of answering user tickets when there's a snag with
> > > > > > OAuth beta.
>
> > > > > > I monitor these forums and the API Issues and still see too many
> > > OAuth
> > > > > > issues being reported to give me a level of comfort that I can
> > > > > > safely
> > > > > > switch over to OAuth.
>
> > > > > > On Jul 24, 5:46 pm, Doug Williams wrote:
>
> > > > > > > Well said Joshua.
>
> > > > > > > Dewald, you have identified the risk of using basic
> > > > > > > authentication.
> > > If
> > > > > > > your users being locked out due to malicious behavior, you should
> > > > > > > either implement further user-level rate limiting on your side or
> > > > > > > adopt OAuth.
>
> > > > > > > Are there any other glaring omissions in our thinking or should we
> > > > > > > proceed with this as our solution?
>
> > > > > > > Thanks,
> > > > > > > Doug
>
> > > > > > > On Fri, Jul 24, 2009 at 11:08 AM, Joshua Perry
> > > wrote:
>
> > > > > > > > Jim's concern is valid, fortunately OAuth is immune to
> > > brute-force
> > > > > attacks
> > > > > > > > once the access key has been issued to an application. For this
> > > > > reason alone
> > > > > > > > I would urge people to switch to OAuth if at all possible. I
> > > would
> > > > > hope
> > > > > > > > (and assume) that if login attempts for an account are locked
> > > > > > > > out
> > > > > that a
> > > > > > > > user would still be able to successfully use an already
> > > authorized
> > > > > OAuth
> > > > > > > > driven application.
>
> > > > > > > > Unfortunately allowing a successful un/pw login while an account
> > > is
> > > > > locked
> > > > > > > > out even when the correct password is presented effectively
> > > bypasses
> > > > > the
> > > > > > > > whole reason for a lockout in the first place, preventing
> > > brute-force
> > > > > > > > password attempts. If an attacker used a dictionary or
> > > brute-force
> > > > > attack
> > > > > > > > and the account was locked out after 15 attempts, then they
> > > > > > > > could
> > > > > continue
> > > > > > > > trying even though the system replied "locked out"; if they
> > > > > event
