The rollback should be deployed tomorrow. Sorry for the delay.

On Sat, Aug 1, 2009 at 23:36, Jesse Stay<jesses...@gmail.com> wrote:
> A timeframe would be very helpful. This is turning out to be a headache as
> I'm testing. If my own user is having to log in over and over to test my
> app, I'm quickly hitting the verify_credentials limit (and I'm even using
> OAuth).  I'm getting really frustrated.
> Jesse
>
> On Fri, Jul 31, 2009 at 8:01 PM, Bob Thomson <stormid...@googlemail.com>
> wrote:
>>
>> 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 <grant.ems...@gmail.com> 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 <d...@twitter.com> 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 <rvizz...@testlabs.com> 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 <d...@twitter.com> 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 <tinb...@gmail.com>
>> > > > > 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 <dpr...@gmail.com> 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 <d...@twitter.com> 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<j...@6bit.com>
>> > > > 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
>> > > > > > eventually sent
>> > > > > > > > > the correct password it would just bypass the lockout and
>> > > > > > > > > they
>> > > > would
>> > > > > > then
>> > > > > > > > > know the correct password.
>> >
>> > > > > > > > > Perhaps Twitter could implement a selective captcha, I
>> > > > > > > > > know they
>> > > > are
>> > > > > > > > > annoying but if executed properly it could be effective
>> > > > protection
>> > > > > > against
>> > > > > > > > > brute-force and dictionary attacks. Say after 3 or 4
>> > > > > > > > > failed
>> > > > attempts
>> > > > > > without
>> > > > > > > > > a captch the API would then include a captcha image URL in
>> > > > > > > > > it's
>> > > > > > response
>> > > > > > > > > that the application would then need to show to the person
>> > > > > > > > > and
>> > > > > > include the
>> > > > > > > > > user's response with the next authentication attempt as a
>> > > > > > > > > header
>> > > > or
>> > > > > > POST
>> > > > > > > > > variable. The site stackoverflow.com does this to great
>> > > > > > > > > effect,
>> > > > if
>> > > > > > you
>> > > > > > > > > create posts quicker than a certain threshold which a
>> > > > > > > > > person
>> > > > would
>> > > > > > not
>> > > > > > > > > exceed then they pop a captcha up, in the normal use of
>> > > > > > > > > the site
>> > > > you
>> > > > > > will
>> > > > > > > > > never see one; I've only hit two captchas in the last in
>> > > > > > > > > the last
>> > > > 8
>> > > > > > months
>> > > > > > > > > using the site.
>> >
>> > > > > > > > > Josh
>> >
>> > > > > > > > > Dewald Pretorius wrote:
>> >
>> > > > > > > > >> Jim raised a huge weakness with the authentication rate
>> > > > > > > > >> limiting
>> > > > > > that
>> > > > > > > > >> could essentially break third-party apps.
>> >
>> > > > > > > > >> Anybody can try to add anybody else's Twitter account to
>> > > > > > > > >> a
>> > > > > > third-party
>> > > > > > > > >> app using an invalid password. If they do that 15 times
>> > > > > > > > >> with a
>> > > > > > Twitter
>> > > > > > > > >> account, the real owner of that Twitter account, who may
>> > > > > > > > >> have
>> > > > added
>> > > > > > > > >> his account a long time ago with the correct password, is
>> > > > > > > > >> locked
>> > > > out
>> > > > > > > > >> from using that app for an hour.
>> >
>> > > > > > > > >> I believe you will absolutely have to reset / remove the
>> > > > > > > > >> lock as
>> > > > > > soon
>> > > > > > > > >> as the Twitter account uses the correct password.
>> >
>> > > > > > > > >> On Jul 22, 4:58 pm, "jim.renkel" <james.ren...@gmail.com>
>> > > > wrote:
>> >
>> > > > > > > > >>> My concern with this proposal is that it opens up
>> > > > > > > > >>> denials of
>> > > > > > service,
>> > > > > > > > >>> not to twitter.com, but to "associated" sites such as
>> > > > > > > > >>> twitpic,
>> > > > or
>> > > > > > my
>> > > > > > > > >>> site twxlate, among others
>> >
>> > > > > > > > >>> For example, Lance Armstrong is a heavy user of twitpic.
>> > > > > > > > >>> It is
>> > > > very
>> > > > > > > > >>> easy for anyone to find Lance's twitter ID
>> > > > > > > > >>> (@lancearmstrong),
>> > > > view
>> > > > > > his
>> > > > > > > > >>> status updates, and see that he is a frequent user of
>> > > > > > > > >>> twitpic.
>> > > > Now,
>> > > > > > > > >>> someone that is "unhappy" with Lance, say one of George
>> > > > Hincapie's
>> > > > > > > > >>> ardent fans that really believes that Lance was a
>> > > > > > > > >>> significant
>> > > > > > > > >>> contributor to George not winning the maillot jeune
>> > > > > > > > >>>  last
>> > > > Sunday,
>> > > > > > > > >>> could go to twitpic, fail to login as Lance the
>> > > > > > > > >>> requisite
>> > > > number of
>> > > > > > > > >>> times, and deny Lance access to twitpic.
>> >
>> > > > > > > > >>> Not only celebrities would or could be subject to such
>> > > > > > > > >>> denials
>> > > > of
>> > > > > > > > >>> service. I notice that @dougw occasionally uses twitpic!
>> > > > > > > > >>> :-)
>> >
>> > > > > > > > >>> One solution to this problem is to add to each twitter
>> > > > > > > > >>> account
>> > > > > > another
>> > > > > > > > >>> "private" ID. By default this private ID would be equal
>> > > > > > > > >>> to the
>> > > > > > > > >>> existing (public) ID (If not equal to the account's
>> > > > > > > > >>> public ID,
>> > > > it
>> > > > > > > > >>> would have to be unique among all twitter IDs, both
>> > > > > > > > >>> public and
>> > > > > > > > >>> private.).
>> >
>> > > > > > > > >>> The public ID would be used just as the existing twitter
>> > > > > > > > >>> ID is
>> > > > now:
>> > > > > > > > >>> others would use it to follow, mention, DM, etc., the
>> > > > > > > > >>> user.
>> >
>> > > > > > > > >>> But the user MUST use their private ID for authenticated
>> > > > requests
>> > > > > > > > >>> through the API, and CAN also use it for
>> > > > > > > > >>> non-authenticated
>> > > > > > requests.
>> > > > > > > > >>> In either case, twitter would treat a request from a
>> > > > > > > > >>> private ID
>> > > > as
>> > > > > > if
>> > > > > > > > >>> it came from the corresponding public ID.
>> >
>> > > > > > > > >>> Blocking the public ID because of excessive
>> > > > > > > > >>> authentication
>> > > > failures
>> > > > > > > > >>> would NOT block the associated private ID unless they
>> > > > > > > > >>> were
>> > > > equal.
>> > > > > > > > >>> Changing your public ID would also change your private
>> > > > > > > > >>> ID if
>> > > > the
>> > > > > > two
>> > > > > > > > >>> were the same before the change, i.e., they would remain
>> > > > > > > > >>> the
>> > > > same
>> > > > > > > > >>> after the change.
>> >
>> > > > > > > > >>> It may seem onerous to require all users to also have a
>> > > > > > > > >>> private
>> > > > ID,
>> > > > > > > > >>> but since it defaults to be the same as their public ID,
>> > > > > > > > >>> only
>> > > > those
>> > > > > > > > >>> concerned about their service being denied would change
>> > > > > > > > >>> it and
>> > > > > > > > >>> subsequently use it instead of their public ID to access
>> > > > associated
>> > > > > > > > >>> sites such as twitpic or twxlate.
>> >
>> > > > > > > > >>> In fact, I think this change, though potentially large
>> > > > > > > > >>> on the
>> > > > > > twitter
>> > > > > > > > >>> side, could be implemented without any changes to users
>> > > > > > > > >>> or
>> > > > > > associated
>> > > > > > > > >>> sites, with one small, obscure exception: now, if I
>> > > > > > > > >>> attempt to
>> > > > > > create
>> > > > > > > > >>> a new twitter account or change the ID of an existing
>> > > > > > > > >>> account,
>> > > > and
>> > > > > > > > >>> find that the ID I want is in use, I can view that
>> > > > > > > > >>> account; if
>> > > > this
>> > > > > > > > >>> were implemented and I attempted to use a private ID
>> > > > > > > > >>> that was
>> > > > not
>> > > > > > the
>> > > > > > > > >>> same as its associated public ID, I could not view the
>> > > > > > > > >>> account
>> > > > > > using
>> > > > > > > > >>> the
>> >
>> > ...
>> >
>> > read more »
>
>



-- 
Alex Payne - Platform Lead, Twitter, Inc.
http://twitter.com/al3x

Reply via email to