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" for each
of these users.
Then when the visitor tries to login, your code can check to
see if the private id the visitor has entered is in your own
database. If so the person is allowed to login, and if not
they get an error.
Would this work to solve the problem of am I missing
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.
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
Are there any other glaring omissions in our thinking or should we
proceed with this as our solution?
Alex Payne - Platform Lead, Twitter, Inc.