This is with regards* to Stack Exchange's upcoming OpenID provider (and in particular, discussion about password requirements).

Currently, password requirements are:

  • Must contain 3 of: lower case character, upper case character, number, special character**.
  • Cannot contain any public account field.
  • Must have at least 8 unique characters.

The rational for the first two I believe is obvious. The last one is to force a certain minimum password entropy, but in a way that can actually be explained to an end user.

I considered a password expiration policy, but discounted it as too intrusive. Users will often use this service as if it were part of the affiliate site, and forcing them to periodically visit it rather than the affiliate site breaks that illusion.

So my question is, are these appropriate password requirements for an OpenID provider; especially one like this which aims for tight integration with 3rd party sites?

*And AviD's suggested it.
**Special character is defined as a non-word, non-digit character.

  • I'm following through here, with my comment on the original thread: Vote to close as S&A. On the other hand, perhaps (since this is particularly related to SE) we might carry this over to Meta?
    – Iszi
    Commented May 18, 2011 at 2:41
  • 2
    @Iszi, this is not subjective, or at least shouldnt be. This is a solid discussion around password policy and enforcement, why do you think it shouldnt be here? Also, its not necessarily a Meta question, even though that is it's source...
    – AviD
    Commented May 18, 2011 at 8:36
  • @AviD - I suppose the issue lies more on "A" side of S&A. The question has already sparked some lengthy comment-debates both here and in its original incarnation. Also, since this is something that in the end will be specifically tuned for SEI, some (if not many) answers will probably end up becoming a bit localized. Threads like this generally aren't well accepted on SE sites because they devolve into long (and occasionally heated) discussions, the general absence of which being one feature setting us apart from other forums...
    – Iszi
    Commented May 18, 2011 at 12:28
  • 2
    @Iszi, naw, this isnt a question about the site, it is a question about security. The kind of thing this site was made for ;)
    – AviD
    Commented May 18, 2011 at 13:54
  • 1
    @nealmcb - code for that is here (through many layers of indirection). The short answer is PBKDF2, using the built-in .NET implementation. Its not really relevant to this particular question, but if you find an issue with it please post it on the meta.SO question (or raise an issue on the Google Code project). Commented May 18, 2011 at 15:56

7 Answers 7


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.

  • +1 Even if only for your first paragraph. But the rest of the stuff here is good, too. I'll have to read that paper sometime - sounds interesting.
    – Iszi
    Commented May 20, 2011 at 13:04
  • +1, even if only for the last sentence re complex tradeoffs.
    – AviD
    Commented May 26, 2011 at 23:47

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.

  • 1
    Mostly good but also a few bad points there. One thing I disagree with is condoning password reuse and condemning written-down passwords. For passwords to use on a website, especially SE, that's exactly backwards. Using the same password on different sites will get you eventually. On the other hand, if the on-file or cached copy of your password is stolen, so is your SE cookie, in all likelyhood. Commented May 19, 2011 at 17:39
  • Agree with @Giles, lot of good points there @D-W and I gave you an upvote. But suggest taking out point on persistent session cookie. It is against OWASP good practice: "Generally it is not recommended to implement a SSO (Single Sign On) solution using cookies; they were never intended for such use. " owasp.org/index.php/Reviewing_Code_for_Session_Integrity_issues . When writing security requirements I usually make sure developers are not doing this.
    – Rakkhi
    Commented May 20, 2011 at 11:14
  • @Rakkhi, What is wrong with using secure persistent cookies for this purpose? The OWASP web page provides no explanation or justification for its recommendation. (Saying "they weren't designed for this" is neither verifiable nor convincing.)
    – D.W.
    Commented May 21, 2011 at 8:37
  • @D-W the main issue even where implemented correctly i.e. cannot access secure cookie over http, is trust placed in the device storing the cookie. If the user is unaware this is happening or a normal user, when they use SE login at an Internet cafe, shared family computer, mobile without pwd etc they are leaving themselves effectively logged in. You could have short timeouts but then whats the benefit of the persistent cookie? If offered as a userbility / security trade-off then it should be via an optional keep me logged in (this is not a public comp) option
    – Rakkhi
    Commented May 23, 2011 at 8:45
  • 3
    @Rakkhi, good point. At the same time, it seems plausible that this may be manageable. When the user logs in from a new computer for the first time, perhaps the site could present the user an option ("keep me logged in / this is not a public computer"), or could ask the user a question ("are you accessing this from a public computer?"). You are right that I was a bit too glib in my answer; maybe the broader point is, given the shortcomings of passwords, it seems worth exploring alternatives -- of which secure, persistent cookies are one.
    – D.W.
    Commented May 27, 2011 at 6:06

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:

enter image description here

  • 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.

  • 1
    Regarding "private data" here, what about careers.SO? What about other sites that may use SO as an OpenID provider? Also, while "regular user accounts can't do any [permanent] damage" high-rep users or diamond moderators can do a good deal of temporary damage.
    – Iszi
    Commented May 18, 2011 at 3:44
  • 1
    @KyleCronin - True, but around here moderators are simply just users who have been promoted. They are held to the same password security requirements (or lack thereof) as Joe User. Also, you still haven't answered for careers.SO. I don't qualify for an invite to say for sure, but it seems that a job-hunting/posting site is going to have a fair deal of information with higher sensitivity than the rest of the SE network. Of course, the argument could be made that even with stricter requirements, people could still use other OpenID providers on SE unless SEI changes that position.
    – Iszi
    Commented May 18, 2011 at 3:56
  • 3
    "Stack Exchange ... user accounts can't do any damage". I absolutely disagree. My online persona is something I care about, it ties into on- and offline friendships, professional networks, career options, and many other things. I absolutely do not want my Stack accounts compromised. Now, whether strict password policies actually help security is a different matter.
    – user2122
    Commented May 18, 2011 at 7:27
  • 2
    @Jesper Well, what I meant was that a compromised user account can't do any damage to Stack Exchange. And if you do value your SE account, there's nothing stopping you from using a very, very strong password. The gist of my argument is that since strict requirements offer no advantage to Stack Exchange and also make it harder for the user, they're counterproductive. Commented May 18, 2011 at 7:40
  • 2
    @Kevin Do you really think you know more about user account security than Facebook or Yahoo? Because I guarantee you there are teams of people at those companies whose job is nothing but making sure the user accounts and passwords remain secure. Commented May 18, 2011 at 17:03

It all depends on context

My baseline advice is:

Do as Google does

Chances are that if they can compromise Google's OpenId security, they won't bother with you. Anything more secure than that needs to be backed up by a very strong added value proposition:

  • We want to be more secure than Google because ____________________
  • It is more valuable for our users to have a less convenient service than Google, because we offer ______________________ as added value

Secondly I can offer this piece of real data:

10% of users will use the same username and password, as measured on some sites I've built, with 50k-500k users.

E.g. user name Foobar123 and password Foobar123.

More in general, making the password more secure is only actually useful if you are implementing the authentication mechanism correctly:

  • User name is not secret but you do not leak whether it exists in your system
  • Password is strong enough
  • The two pieces of information are completely independent:
    • Different
    • Never stored or sent together (you'll love this—including in other sites where they might be used).
  • @Sklivvz - "Never stored or sent together"? I'd like to hear more about how this is done, or does the trick lie in defining the term "together"?
    – Iszi
    Commented May 18, 2011 at 14:06
  • @isz: user + hash(password) would satisfy the first bit. The second is satisfied by not sending an email "thanks for registering, your username is this email address and the password is xxx" (for example). It's really impossible to ascertain that the same combination is not used elsewhere though -- that's a well know security issue that all web sites face (not being able to avoid it does not mean it's not there :-))
    – Sklivvz
    Commented May 18, 2011 at 15:05
  • I'd say we're doing approximately what Google does. Same minimum password length, with a "strength" check (Google's is opaque, but presumably entropy based; ours is clearer to the end user, and uses unique character count & character class check as a proxy for entropy). Would you agree? Commented May 18, 2011 at 17:54
  • @Kevin, I would not agree. While I don't have data or analysis to back it up, I suspect your proposed restrictions are more restrictive than Google's. I would also question whether a complex set of restrictions will be clearer to the user than a dynamically-updating strength bar.
    – D.W.
    Commented May 19, 2011 at 7:37
  • 1
    @D.W. - we have the dynamic feedback, the difference between us and Google is we tell the user what they're missing rather than "nope, needs to be better (and you get to guess how)!". Commented May 19, 2011 at 15:47

The 8 unique characters is a bit on the excessive side.. Just checked and there are fewer than 1500 words in English dictionaries, with 8 or more letters that are all unique, so what you are also doing is not accepting dictionary words. Not that this is a bad idea, but you could say just that 'dictionary words are not allowed'.

Of course this will frustrate users, and will make many of them type recognizable keyboard patterns, like every letter in a row. Those patterns are there in the dictionaries of every good cracker.

Edit: I couldn't help myself, had to post this here: http://popstrip.com/password-validation/ :-)

  • First, we want to discourage dictionary words! Second, this doesn't require that all the characters be unique. It requires that there are 8 unique ones. So if you've got 8 chars and one dup, just add one more character.... So any dictionary word works, but you might have to add more.
    – nealmcb
    Commented May 18, 2011 at 14:45
  • 2
    Also, the moment you require numbers you already disallow dictionary words as passwords :-)
    – Sklivvz
    Commented May 18, 2011 at 15:09
  • @nealmcb: You are correct, I didn't suggest encouraging them, I didn't write it clearly so I edited the answer. Anyway, it was just a suggestion about the recognizable patterns, didn't catch that passwords shouldn't be all unique at first read. @sklivvz: most crackers use permutations so they can easily find a dictionary word with one number added.
    – john
    Commented May 18, 2011 at 17:11
  • 1
    I think the more important point that John made is that these restrictions will make many users type recognizable keyboard patterns (e.g., "zxcvbnm,").
    – D.W.
    Commented May 19, 2011 at 7:38
  • @D.W. As the paper I point to in my answer makes clear, any good scheme should also include a blacklist to prevent such keyboard patterns from being chosen. And @john, talking about 1500 "all unique" words has no bearing on this question - that is not a requirement here.
    – nealmcb
    Commented May 19, 2011 at 22:40

I love how we are having this debate still in 2011. I wonder in another 10 years whether we will still be discussing the most appropriate password policy.

I agree with @Kyle-Cronin that the right way to approach this is to examine the risk:

  • What is the value? For standard users just the Stack Exchange (SE) account is of low-moderate value. It is not a a throw away subscription, reputation and online profile are important but less so than email, social networks, online banking, payment systems. Moderators could have slightly more value but still not high. An interesting question is raised by @Iszi on whether as a Federated Identity provider if there is a responsibility or duty of care to provide more security than the original site warrants simply because it could be used by more valuable sites. You could rely on the user to set a stronger password if they use SE Open-ID on more valuable sites but this may not happen. Alternatively setting the maximum just in case the ID is used for say Internet banking seems overkill. Arguably these sites would consider the context that SE is used and seem unlikely to offer SE Open-ID therefore they can be discounted. The most likely sites to use the SE Open-ID are social network and start-up sites looking to support a wide variety of federated logins and target the various SE communities as customers.

  • Threats and motivations? The main threats for SE accounts are probably spammers. They are motivated but use a dragnet approach seeking the largest possible coverage with the least resistance. Potentially disgruntled or malicious users who want to escalate privileges to moderators, trash other users etc however these would probably not have very high motivation to subvert basic password controls. Social networks and other start-ups that use SE Open-ID are not likely to face highly motivated attackers at least in the beginning. Later if they perceive a higher risk they would probably re-consider their support for SE Open-ID or add additional controls e.g. adaptive authentication or fraud monitoring systems.

  • Vulnerabilities? The main attacks that a password policy will defend against is brute forcing or guessing a password. With an exponential back-off or a short account lockout even a 6 character password can provide a reasonable level of difficulty to brute-force or guess. Especially against the type of threats and motivation levels we anticipate. Larger and more complex passwords would really only defend against someone obtaining the full or partial database of passwords. Assuming a reasonable multi round hash and seed method with bcrypt etc as well as a reasonable infrastructure controls this is sufficiently low probability for the SE threats that it is not worth the useability trade-off

  • Risk summary: Overall the risk for a standard user is low with a basic set of password policies place. Moderators face a slightly higher risk and users that utilize the SE Open-ID for more sensitive sites face the highest risk of all.

Therefore I suggest a segmented set of password controls to present the best balance of risk and useability:

Standard users:

  • Minimum length 6 characters. Even though MyOpenID offers 1 character most users now are used to about a 6 character password and this should not put off many users from joining and using the site and be memorable enough. As stated this is what is used by Facebook and Yahoo
  • Show simple password strength indicator updated as they type but do not mandate any further. Encouraging a user to utilize a password vault to generate the password here on the UI is also a good idea
  • Exponential back-off 2 seconds on every failed attempt doubling with each failed attempt

Moderators (Additional):

  • Must contain 3 of: lower case character, upper case character, number, special characters
  • Cannot contain any public account field.
  • Minimum password length 8 characters

When a user becomes a moderator they can be prompted to change their password with the new requirements

Authentication for other sites (Additional):

Any user that uses the SE to authenticate to x other sites (x could be configurable 3 is probably a good number when the risk increases to warrant sufficient security). As I don't think there is any good way to judge the risk of the sites SE Open-ID is used for without maintaining a manual list and knowing the users risk profile a basic number of sites linked is sufficient. This should also apply for higher sensitive SE sites like careers.stackoverflow.com as this is storing personally identifiable information.

  • Offer a two factor option e.g. SMS on time password, soft token like Google authenticator. Not sure if this could be developed and supported cost effectively by SE

When a user links additional sites they can be prompted to change their password with the new requirements

8 Unique characters is a nightmare for usability and offering two factor would be a lot better option for this risk level. Password expiry also is more detrimental than beneficial so I'm glad that was not proposed.

  • 2
    Note that the role of the users is completely delegated in open id. You only offer an authentication service, not an authorization service. In practice, you are never able to know if the user is "standard", "moderator"...)
    – Sklivvz
    Commented May 18, 2011 at 15:08
  • Internally within SE know the authorization role though. For Federated I agree, that's why I suggested count number
    – Rakkhi
    Commented May 18, 2011 at 16:02
  • 1
    Increasing password requirements with changing roles or authorizations is unworkable. We can't trust affiliates to notify us w.r.t. "more privileges granted to {account}" (I'm opposed to treating Stack Exchange specially in the provider, so we can't trust ourselves even). That's assuming the sites involved are even properly registered as affiliates, and not just random OpenID relying parties. Commented May 18, 2011 at 16:33
  • 1
    You could always just include something about double-checking the security of your OpenID provider and password in the agreement that moderators agree to before they can start moderating. Being a moderator means that there's already a great deal of trust in you, I think that we can reasonably expect moderators to take their passwords seriously. Commented May 18, 2011 at 17:11
  • 1
    @Rakkhi - Thank you for acknowledging the question of SE OpenID usage on other sites. Can you please also address the other point I've raised, of the specific case where SEI is both the OpenID provider and the provider of an online service with higher information sensitivity such as careers.SO?
    – Iszi
    Commented May 19, 2011 at 4:49

You should add that:

  • No passwords should be their user names (that is just stupid but happens).

  • No actual words, or at least a word combination that is not in dictionaries (I learned from a website about cyberspace problems and one of them was about problems. It said that sometimes hackers attack and hack with computers that could find words and then predict your password like that).

  • Passwords should also be complex, unique but easy to remember like a sentence with the beginning of each letter somehow changed.

  • You could completely not let people finish their sign up process unless they put at least some numbers and a capital letter with some other things, like H3110!:|.

  • you could also add a checker to see lets them see their password's strength

  • Try adding in 2nd and 3rd passwords with their phone number and other personal things like their thumb print (this is inspired by Google) so that way the hacker has to literally "be" their victim in order to get past.

  • Try encrypting their information with another password that just the person knows in case of an hacker ever successfully hacked in, so they can't get through this password either very easily.

  • I know this one is going to be hard to add but maybe add an little companion on your website/place/whatever that knows their personality so if it sees a change, it would probably guess it would be a hacker unless the person said so in the first place. Kinda like a personality software for every user (everyone is different after all).

  • Also alert them if anyone else besides who they know goes on to their account. If they say they don't know who that person is it is probably a hacker then (Google does this).

  • For phishing mails/things/whatever try scanning them first before letting them see it (test if it's safe), them ask them about it, and if they say no, destroy it, preventing them to be tricked by the hacker.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .