OAuth does not use any real "login credentials", if you consider login credentials as a username/password set. Unless you're using xAuth, I don't think you'll need to worry too much.
On Jun 17, 4:17 am, Jonathon Hill <jhill9...@gmail.com> wrote: > I'm trying to get approval from PayPal to use their Preapproval API, > and to do so my application must meet several requirements. I won't > post the entire list here, because it isn't applicable to Twitter, > however since users log in to my application via Twitter OAuth several > of them are applicable: > > ---- > > A1. User passwords must conform to industry best practices for content > > Generally, the length should be at least 6 characters, and contain at > least one alpha and one numeric. Candidate passwords which meet the > static syntactical requirements should also be passed across a > dictionary of common passwords, and rules – no passwords of > “blink182”, or passwords which are the same as the user-ID, for > example. > > ---- > > A6. A control must be implemented that prevents the brute force attack > of login credentials. > > A common attack against web sites is to attempt to login in with a > variety of different commonly used passwords for a given login id. > There must be some method used to ensure that one is unable to perform > this sort of attack. A common solution is to lock login attempts on an > account for some period of time. In order to ensure that these > mechanisms do not generate a means of denial of service attacks > against accounts, these lockouts should cancel after a period of time > (a few hours is typical). > > ---- > > A7. A control must be implemented that prevents brute force guessing > of passwords, especially if the attack is originating from a botnet. > > Typically, this will require collecting metadata about logons, logging > them into a central log store, and then performing real-time analytics > against that data. If a brute force attack is detected, a strong > CAPTCHA (resistant against machine/scripted attacks) would be switched > on. There are other implementation techniques, but this is the least > invasive from a user experience perspective. Note – this is > conceptually and functionally different from A6. > > ---- > > B1. Login credentials must only be collected on pages that implement > https with Extended Validation (EV) certificates. > > In order to allow customers to verify that they are truly connected to > the partner site and to encourage general good practices, login > credentials must be collected on pages that are https enabled, and > using Extended Validation (EV) certificates. > > ---- > > So, my questions are: > > 1. Would you guys be willing to add to your API to allow enforcing > tighter password requirements as needed? > > 2. Will you upgrade your SSL certificate on api.twitter.com to one > with Extended Validation? It seems like this would be relatively easy > and inexpensive to do, and beneficial to all. > > 3. How doeshttps://api.twitter.com/oauth/authenticaterespond to > brute-force attacks on login credentials? > > Thanks! > > Jonathon Hill > @compwright > @rainmakerapp
