Appropriate password requirements for a login (OpenID) service/provider/delegate/thing
The proposed restrictions are harmful. These restrictions are overkill. They are bad for usability. As a result, I think they will harm users' security more than they help.
Usability is where it's at. In my opinion, right now the #1 most important factor affecting password security is usability: the extent to which users use the mechanism in a way that is secure. To a first-order approximation, everything you should do should be aimed at increasing usability and increasing the likelihood that users will behave securely. Every time you have a design decision, you should ask yourself: which option is more likely to cause users to behave securely?
I would expect that the complex restrictions you have articulated are, on balance, harmful to the user's security. I think they will decrease security more than they will increase it. Here are my arguments:
Frustration. One risk is that users will get frustrated or annoyed, give up, and shift to some other OpenID provider that is less securely administered than SO is -- or just stick with their current SO, instead of adopting SO's OpenID provider. That is a net loss for the user's security.
Making it hard to memorize. If you have unique restrictions that are specific to SO's OpenID provider, this means that the user will have to pick a unique password for your site. This may sound like a positive, but it could equally well be a negative. If the user already has a high-entropy secret, they likely can't use that one, because odds are it won't satisfy SO's restrictions. I suspect this fact increases the likelihood that the user will be forced to write down their SO password somewhere rather than memorizing it.
Automated password generators. People are, generally speaking, bad at picking unguessable password. To address this, some folks use tools to generate their password for them. Some have even advocated that these tools should be more integrated into everyone's browser and used widely. Right now the biggest barrier to use of automated password generation lies with sites that pick their own special set of restrictions on password. Thus, your proposed set of restrictions will make it hard for people to use automated password generators. That's bad; you want to encourage people to use automated password generators, because automatically generated passwords will be more secure. And you don't want to create barriers to integrated password generators.
So what should you be doing? I have two pieces of high-level advice:
Start with a threat model. Don't just start making up restrictions and security schemes that sound good. Instead, start by thinking about the threat model. What do you think are the most likely ways that security will fail? Then, when you come up with a new idea, rather than immediately implementing it because it sounds good, analyze how it will affect each of those likely failure modes. Does it, on the whole, significantly reduce the likelihood of the most-likely failure modes? Just as there's no point strengthening the strongest link in a chain, there's often little point in securing against a threat that's not actually very likely.
I notice that the question describes a security mechanism, but it doesn't describe the threat model, and it doesn't contain analysis. It doesn't state exactly what attack it is aimed at defeating. In the security design space, this is a "bad smell" which often indicates that perhaps more thought may be appropriate.
For an example of this kind of analysis, you might read this analysis. The paper argues that about 20 bits of entropy are sufficient for web passwords, as long as the password verification software is architected reasonably, and argues that there is little benefit to passwords with higher entropy. See the paper for the detailed analysis. The paper's conclusion states "We conclude that forcing users to choose strong passwords appears misguided"; see the paper for why.
Cost-benefit analysis. It is important to assess the costs and benefits of the mechanism, and make sure that the costs are justified by the benefits. In this case, the costs are user annoyance. The security benefits of these restrictions, compared to some less strict restrictions, are unclear and probably minor.
I encourage you to read Cormac Herley's economic analysis of password security. He points out that the advice that security experts give users about passwords is irrational: the costs to users of following that advice (e.g., their time wasted in selecting, memorizing, managing and entering complex passwords) likely exceeds the benefits (in reduced security breaches) by a large margin. He argues that any restriction which consumes more than a few minutes of the user's time per year is almost certainly a net loss, and in practice I suspect it probably needs to be at least an order of magnitude lower than that. Someone asked for data; he has it.
On a related note, Cormac Herley has also performed a study of the password policies on 75 different websites. He found a broad range of restrictions. He also found that the degree of restrictiveness is not correlated to the security sensitivity of the site, and suggests that "the sites with the most restrictive password policies do not have greater security concerns, they are simply better insulated from the consequences of poor usability." This should make one think twice about the suggestion that stricter password restrictions are better.
If you're looking for more concrete steps you could take to protect your users and increase the likelihood that they pick secure passwords, here are a few ideas you could consider:
Include a password strength bar. On the form where the user has to pick a password, include some Javascript to provide a dynamically updated bar that shows how strong the user's password is. You can go with red, yellow, green for insecure, borderline, good.
Include a pre-generated password suggestion. On the form where the user has to pick a password, you could randomly generate a password for them and suggest they use it. Maybe some will use it!
Help users avoid popular passwords. One recent research paper proposes an interesting idea: they suggest that users should be able to choose any password they want, as long as not too many other users have previously chosen it. Then, they describe how to enforce this policy, without storing passwords in cleartext on the server.
Use secure, persistent cookies for user authentication. If you reduce the frequency at which users will have to type in passwords, maybe users will be more willing to pick complex passwords of their own accord, and maybe users will be less likely to be fooled by phishing attacks. I suggest that your site set a secure, persistent cookie on the user's browser when the user first logs in. On future visits, if you detect that cookie, immediately treat the user as authenticated and redirect them onto their final destination, with no user interaction required, so that users are logged in without having to type their password.
Focus more on the password verification step. Why do we want users to pick high-entropy passwords in the first place? What are the attacks we are concerned about? One kind of attack is a targeted attack, where the attacker has a particular username in mind and wants to break into that user's account. Another kind of attack is a broad attack, where the attacker has a ton of usernames and wants to find one, any one, whose password he can guess. What's the biggest threat for the SO OpenID provider? I suspect the one you should worry most about is targeted attacks, because I suspect an attacker is more likely to be motivated to try to break into a moderator or high-ranked user than an average user.
Stopping targeted attacks. There are effective ways to prevent targeted attacks on a single user's passphrase. One very simple way is to keep a count of how many incorrect passwords have been entered in the past day or so. If this count goes above some threshold, then you switch to "oh shit, I might be under attack" mode. In that mode, you can require the user to enter a CAPTCHA along with each password, or you can add a delay after each attempt, or rate-limit login attempts, or you can force the user to solve a proof-of-work challenge (e.g., serve the user some Javascript code and force them to do 20 seconds of computation before you'll accept the next password guess), or some subset of these. There are many possible schemes.
Stopping broad attacks. If you want to defend against broadscale attacks, e.g., where the attacker tries one password guess against each of tens of thousands of accounts, you'll need different defenses. But there are also schemes for dealing with this problem as well. One potential countermeasure is to keep track of the overall rate of incorrect passwords, and enter "I might be under attack" mode when this rate starts to get high.
There is a rich literature on defending against these kinds of attacks. Overall, I think you'd be better off making it harder for attackers to mount password-guessing attacks (e.g., making them run slower), rather than imposing additional restrictions on user passwords. I think there's more bang-for-the-buck there.
The question specifically notes a requirement for "tight integration with 3rd party sites". So all the arguments about how unimportant SE accounts are is besides the point.
Also note that no one is forcing anyone to use this particular OpenID service. There are many to choose from. Differentiation on the basis of good security seems like a good idea for an authentication service.
Bad passwords are a huge issue in the world. Users may well reuse the same password elsewhere. Educating users about how to make a good password is a very valuable service to the Internet. The cost to the user of using a good password is small, especially given the convenience of good and secure agents (in browsers or elsewhere) to remember them.
Sites with valuable information like passwords should plan to be compromised, and plan on how to minimize the damage. Even with a good hashing algorithm like bcrypt, passwords with low entropy can be brute-forced. So good passwords remain a good idea.
So what policy is best? We all have opinions, but there is actually data out there. One interesting new paper is Reusable Security: New Paper on Password Security Metrics. (Update:) It notes the importance of checking proposed passwords against a blacklist of common ones (including things like rows of keyboard keys). It also floats the idea of an interesting new password reject function which also suggests modifications of the proposed password that use the user's basic chosen pattern, but make the password more unusual and thus harder to crack:
[first] evaluate the probability of a human generated password by parsing it with a grammar trained on previously disclosed password lists. This allows us to build a more robust reject function compared to a simple blacklist, while attempting to provide the most user freedom possible, given the security constraints of the system, when selecting their passwords.
Based on the above, the proposed policy certainly seem like the kind of pro-security differentiator that I would look for as a 3rd party site interested in adopting the Stack Exchange OpenID provider, if I wanted to lower the risk of passwords being cracked.
(Update:) On the other hand, if your goal is to attract users to your OpenID service, a scheme that is less likely to frustrate them (as D.W. describes) might be a better business decision. Ultimately, your goals are probably diverse, and the tradeoffs are complex.
Complex passwords are often enforced by an organization's IT department to ensure that the user accounts of employees aren't externally compromised. They're also enforced in situations where a user is trusted to have access that could be damaging in the wrong hands.
In this case, neither situation applies. Stack Exchange doesn't store any private data, and regular user accounts can't do any damage. The only case where these password requirements might make sense is if the Stack Exchange systems were compromised, everyone's password hashes were exposed, they could be easily cracked, and users used the passwords elsewhere. No other scenario makes sense - Stack Exchange can throttle brute force attacks; if the login system is compromised password strength is useless; and even if the user's password is compromised, the damage it can do on Stack Exchange is quite limited. So in all cases, Stack Exchange is not affected by the strength of the passwords of their users.
On the flip side, the strong password requirements will likely cause many people to avoid using the service, and stick with their Google or Facebook accounts, both of which have far fewer restrictions on what the password can be.
This is an issue of degree - how secure can you force people to be before they either avoid your service or sabotage your attempts to "secure" them. For example, someone may have a password they would like to use, but it might not have 8 unique characters, so instead they use "Pas$word". Or they make up a password but know that they won't remember it, so they write it down somewhere that anyone that's near them could see it.
To provide some perspective, here's an examination of the password restrictions that the other OpenID providers prominently featured on the Stack Exchange login pages have:
Google: 8 character minimum, must also not be a "weak" password, though the exact mechanism they use to determine a "weak password" is obscure. ("abcdefgh" and "abcdefg1" are weak, while "Abcdefgh" is sufficiently strong). They do provide a page with tips for a stronger password.
Yahoo: 6 character minimum. There is a graphic similar to Google's that shows how strong your password is, but nothing prevents the creation of an account with a weak password.
MyOpenID: 1 character minimum, no other restrictions. Similar to Yahoo, there's a graphic that shows how strong the password is (source code), but nothing prevents the creation of an account with a weak (or even 1 character) password.
AOL: 6 character minimum, must also not be "too insecure". There is a password strength meter (source code), and it seems that any password that gets a score lower than 34 is considered "too insecure".
Facebook: 6 character minimum.
Compared with these, the restrictions on the Stack Exchange OpenID password are far stronger. Unnecessarily so, in my opinion, given that the largest pure OpenID provider, MyOpenID, has absolutely no password restrictions at all.