Anyone has research or data that shows correlation between using password complexity requirements and sign up conversion rate?
Example of password complexity requirement:
It's tempting to just cite this: https://xkcd.com/936/
... But maybe this study is more in line with your question. That directly addresses password security relative to user resistance (though maybe not conversion rate). It does so in the context of comparing password security models, which might go even further to answer your question.
Essentially, the xkcd punchline is supported by the Carnegie-Mellon study: "Through 20 years of effort, we've successfully trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess."
Password security modeling partly depends on the scenario you are defending against. But we seem to be coming down to resisting brute force attacks, for which you just need as much entropy as possible. That just means more characters, and we can stop torturing users by forcing them to expand the character set to special characters, numbers, etc.
The xkcd example in which "Tr0ub4dor&3" would take 3 days to crack at a certain level of hardware, and "correct horse battery staple" would take 550 years at the same level, is a good example.
The CM study does show that as of 2010 there was slightly added user resistance to a 16-character requirement, but that's very possibly a sentiment that can shift over time, and users may have been assuming they still needed to avoid dictionary words or include a variety of character types because of previous experience. For those users, it's just a longer version of the things they already didn't like about creating passwords.
But as we move forward and set friendlier expectations, in friendlier ways, that might prove to be a minor resistance that was only temporary. Even "correct horse battery staple" is in fact no more secure than "wow the lawn is really green" and much harder to remember, so advising users to create a mnemonically memorable sentence related to the site may actually flip the long password requirement to being a positive experience.
All the normal practices for a) giving clear parameters up front and b) graceful error states remain true, but a lot of them are less needed if you get rid of all the cruft that grew up around password criteria that turns out to be non evidence-based.
I think one should always expect the dumbest user (we everyone have our dumb moments ;) ). So, make the minimum restrictions, and explain what's wrong. I suggest using little absolute restrictions. Instead I would use a formula that evaluates the risk of the password, and if it's high explain the main problems to the user.
User types "password123", system says:
«Your password it is too risky:
Where to start:
I wouldn't overthink this problem -i.e., don't wait around for a study that shows the bounce rate at the point of entering password.
You can trust that if people are willing to enter a password, they will not change their minds because you've added a few security features. It is safe to assume that people have their go-to password that meets most requirements - unless you are dealing with a primarily 60+ crowd, and then you need to be very forgiving when it comes to password creation anyway.
That being said, you can make friends with them if your experience isn't overbearing. They won't take off, but they might build a little animosity toward you if you act like a password nazi. You can help their brains along a bit by:
• Chunking: Give 1-5 rules for the password, no more than 5, and the fewer the better.
• Avoiding crazy rules they've never seen before. (The above example has a couple that are unordinary)
• Giving them a mobile-friendly size of field to create their password and a nice clear submit button.