Perhaps a better approach to the lockout:
Lock the account for x minutes after 15 *unique* bad passwords. So if
the user changes their password, and another program keeps trying with
their old password, that only counts as 1 attempt.
It still only gives them 15 guesses, but would cause fewer loc
We've just heard from our operations and deploy staff that we won't be
able to deploy any code (for the API or otherwise) until Monday due to
the DDoS attack and other issues. That means that the revert to the
old rate limiting policy for this method won't go out this week. My
apologies.
On Thu,
Alex, is that *not* estimated or was it an iPhone being daft and
changing now to not?
On Aug 5, 7:11 pm, Alex Payne wrote:
> The change did not go live yesterday due to some deploy issues. It's
> not estimated to go out tomorrow. Once again, sorry for the delay.
>
>
>
> On Wed, Aug 5, 2009 at 07
The change did not go live yesterday due to some deploy issues. It's
not estimated to go out tomorrow. Once again, sorry for the delay.
On Wed, Aug 5, 2009 at 07:48, Dewald Pretorius wrote:
>
> Alex,
>
> Did the change go live on Tuesday?
>
> I have very irate users due to this issue. There are s
Alex,
Did the change go live on Tuesday?
I have very irate users due to this issue. There are spam bots out
there that got hold of users' credentials. The users have changed
their Twitter passwords to get rid of the spam tweets published in
their timelines, but now those bots are locking them ou
It would appear not - just tried our app and after 15 page loads it
breaks. Our site uses OAuth to sign users in, so we use
verifycredentials on each page request to ensure the session is still
valid and return user details. On our system it is quite likely that
the user will see more than 15 pag
Would it be possible to have an update on this issue? It seems it's
stifling a lot of developers, me included.
Did the rollback happen?
On Aug 3, 6:56 pm, Alex Payne wrote:
> The rollback should be deployed tomorrow. Sorry for the delay.
>
>
>
> On Sat, Aug 1, 2009 at 23:36, Jesse Stay wrote:
> > A timeframe would be very helpful. This is turning out to be a headache as
> > I'm testing. If my own user is
The rollback should be deployed tomorrow. Sorry for the delay.
On Sat, Aug 1, 2009 at 23:36, Jesse Stay 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 ver
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 P
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
pr
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 prop
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
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
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 rollba
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
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 t
Seems fine. Is there a timescale for rolling this out?
On Jul 24, 9: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
I would much rather have Twitter lock me out of my account for an hour then
let some script kiddie brute force my password. Thanks Twitter.
Abraham
On Fri, Jul 24, 2009 at 14:51, Marco Kaiser wrote:
> I think Dewald's concern is very valid - and even though OAuth might solve
> it, the reality i
I think Dewald's concern is very valid - and even though OAuth might solve
it, the reality is that most (if not all) desktop and mobile apps are using
Basic Auth today for various reasons, so if you implement this policy as
described, there's a pretty high risk that many users can be locked out of
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 shoul
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 th
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 acc
What do you mean the change won't affect OAuth? My application has
been suffering from this issue ever since you made the limit change.
My application has the ability to use either Basic or OAuth. My
twitter users get blocked with the 403 error after a few minutes of
usage because they reach the 1
Why will it not apply to OAuth? OAuth is having this problem too!!
Not happy!
On Jul 23, 12:15 am, Doug Williams wrote:
> Scott,This change will only affect Basic Auth, and will not affect OAuth
> applications.
>
> Thanks,
> Doug
>
>
>
> On Tue, Jul 21, 2009 at 4:27 PM, Scott wrote:
>
> > Than
Jim,
What you're suggesting is basically what they offer with OAuth. Apps
are given a token to represent logins and a secret key to represent
passwords for their authenticated users. Both are very long and
impossible to guess. This mechanism works very well and basically
corrects all the issue
Owkaye,
Thanks for the comment and suggestion.
The problem with implementing this locally at associated web sites
rather than centrally at twitter is that:
- each site would have to implement it separately; and
- users would have to sign up and create a private ID at each site
they use.
That re
Scott,This change will only affect Basic Auth, and will not affect OAuth
applications.
Thanks,
Doug
On Tue, Jul 21, 2009 at 4:27 PM, Scott wrote:
>
> Thanks for the update Doug. Does this still apply to OAuth apps?
> Also, if a user goes through an app and unsuccessfully attempts to
> login
> One solution to this problem is to add to each twitter
> account another "private" ID.
Jim,
Wouldn't it make more sense to implement this "private id"
thing on your own server?
My thought here is that your service should maintain its own
database of users, and issue a unique "private id" fo
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), v
Making calls to protected methods like direct_messages will fail if the
token is no longer valid. It is also possible that the test method will fail
with incorrect authentication info/oauth token. I have not tried it though.
Abraham
On Wed, Jul 22, 2009 at 03:10, Goblin wrote:
>
> I've been upda
I've been updating my site to use OAuth and have found this to be a
big problem. Without the ability to call verify_credentials I haven’t
found a reliable way to ensure that logged in users with a valid
session are still authorised with Twitter. It's unlikely they will
revoke access in the middle
Josh, is there a way, without verify_credentials, to identify that users
have changed their Twitter passwords (and therefore you are no longer able
to authenticate for them)? For client apps, I don't see this being as much
of a problem, but for server-based apps that run regular scripts on behalf
To be honest ever since the x-rate-limit HTTP headers were added we
removed the call to verify_credentials from our Twitter API layer.
Every time that our Twitter API layer does an HTTP request it
squirrels away the header values and any requests to our API from the
application for rate-limit inf
Thanks for the update Doug. Does this still apply to OAuth apps?
Also, if a user goes through an app and unsuccessfully attempts to
login 15 times will that app be blocked from authenticating anybody
for an hour or just that user? The previous change seemed to block
the entire app from making an
35 matches
Mail list logo