119

If the user can type it then it should be allowed in their password. Telling someone what they can and can't use in their password always feels wrong to the user. Passwords are currently the most universal way to authenticate. Preventing users from entering anything is, in essence, telling them who they can or can't be. 1. Any printable character that a ...


39

If you are providing a valuable service/product there will always be people trying to "cheat" the system and get in. Providing a free trial period is an industry norm and over time users may sign up for more than one trial but that will get old fast. I would worry less about ensuring authentic users and focus more on providing that great content. If you're ...


35

If a site requires that passwords only contain certain character codes, then a user will be able to enter the password into almost any device which is capable of producing those characters. If the password contains character codes which may be entered on some devices but not on others, then a user who creates a password on a device which could enter the ...


30

It's better to use a special one-time login url. Reasoning: You want to make the process as easy as possible to have the lowest drop-off rate. Sending someone a temporary password requires them to either retype a password that they haven't chosen, or copy and paste it. It also provides no additional security benefits.


30

Let me post an answer contrary to existing ones. A "login successful" message is not just unnecessary but it's also wrong. Why Unnecessary Think if objects/devices you use in everyday life will give you feedback each time you use them: "OK, you're using right key, you can turn the car's engine on", "Welcome back Adriano, this is your house", "Your PIN is ...


29

Cutting it down to a single step makes the process simpler and better fits existing conventions, so it's probably superior from a UX perspective. Each additional step you introduce is more work for the user. Add in the potential for users waiting between page loads (especially on mobile) and you're really just adding an additional inconvenient step in their ...


26

You shouldn't enforce the characters in passwords. Instead you should encourage passphrases which although longer are more secure and easier to remember. Instead of trying to explain this, I will let XKCD do it for me:


24

Every constraint you add to a password pattern, the more cognitive load you add to a user. And constrains can be good to make a password secure. But how secure is a password that user constantly forget and as a consequence hit the “forgot password” workflow yet again. Further you minimize the option for users to use there already memorized secure password on ...


20

I would like to add to DaveAlger's point. I, like many people, create algorithms in order to better remember passwords. I've spoken to many people (in an informal manner) about passwords and I have heard a lot of objections why can't I use a part of my email or my username in my password? why is there a character limit? (affects my algorithm) why can't I ...


19

Workflow-wise, 1 step is a no-brainer. It's three fields and there's no reason to separate them. You can also nicely inline validate all 3 fields at once; what if my passwords don't match on the second screen in 2 step? Is my old password still valid? If not, that's a pain in the butt. If so, that's a potential security risk! Actually a two step seems ...


18

First of all, you shouldn't require such convoluted & complicated passwords. Instead, you should simply put a password strength meter next to the password field and let users decide whether they want a strong password or a weak one. Secondly, your system shouldn't have 2 different ways of dealing with wrong and/or invalid passwords. It should simply try ...


15

This is a tough issue that I'm not sure anyone has really solved yet, but here are my thoughts for your 3 solutions. Phone number Yes this might be a bit personal or creepy but I feel like it's becoming less so since people are actually using their phones less and less. You'll want to be clear that you're not selling their phone number to a marketing ...


14

TL;DR - Most of the time I've seen people add this feature it's been pure security theatre. It hasn't helped the user and doesn't make the site safer. Avoid if possible. The long version... Personally - I'd start questioning whether this was actually a good feature to add. Is it actually making the system more secure? Are there better ways to make it ...


13

Consider using federated user authentication from some social network like Facebook or Twitter. You can suggest to your user that your use of social credentials is a service to them, saving them the hassle of remembering and maintaining a different username/password set for your site. Should they change their password on the social network, your site would ...


11

Jumping in with an answer because I've seen a really nice example of this in the wild. Hargreaves Lansdown is a UK financial institution, and here's how they do it: The idea of giving context to a user hadn't occurred to me before I saw this. In practice, I find it far faster and easier to input a password when I can see how far the requested characters are ...


9

As a one-off authentication scheme it's okay, but the problem arises when you need to post more than one comment. You'd have to send the confirmation email each and every time. There's no client-side authentication, so there's no way to set up things like an avatar (unless you use Gravatars), display names, edit comments or post new comments without going ...


9

You need it for a simple reason, so that you can ensure that people haven't used someone else's email to sign up for your service. Another reason for email verification is that people might identically enter their email wrong and an email verification step helps them check that they had used the correct email to sign up. An alternative approach you can use ...


9

If any service can validate what the n-th character of your password is, it means that they are storing your password in an insecure format. No service should ever know what your password is, they should only be able to say whether your password authenticates or not. So you shouldn't ever ask for the n-th character of a password, and you shouldn't ever be ...


9

HSBC uses a combination of a username, password, and security key. In this implementation, you first enter your username. Next, you are prompted to enter your password and three random characters from your security key: download bmml source – Wireframes created with Balsamiq Mockups The benefit of this approach is that the password does not ...


9

Honestly, a valuable product. You are not the first one to offer trials. You would scare more potential customers off than you would save through fraud-detection processes. If your customers like what you do, they will pay for it. If they use your software on a regular basis and still create a new account each time, they can't or don't want to afford it. ...


9

Right now, you should not be solving this problem. Not only is it a problem you do not have, but solving it too early may mean you will never have the problem. Lemme splain. Lemme sum up. The more you try to reduce the % of fraud, the more it costs to prevent each instance of fraud. This cost is in the time you spend directly preventing fraud, the ...


8

There are very few times when I feel it is appropriate to only have external logins. If what you're doing is tightly coupled with the service that you're using for a login (e.g. Klout using Facebook and Twitter), then I'm willing to make an exception. I know some of the Stack Overflow guys might disagree with this (see here), but I prefer to keep things ...


8

More than necessary, I think the word is convenient or recommendable. and of course, the message or its phrasing doesn't need to be the one you mention, as long as there's a clear indication of a change of status. The change of status is obviously the difference between logged and no logged, and it can be represented by messages (like yours), change of ...


7

Like you say password pattern enforcement is basically a good way to make sure that the user is going to invent a password that is optimised to be forgotten. This is especially true of rules that are quite complicated (one I recently came across demanded that the password have at least one capital letter, one digit, one special character, be at least 8 ...


7

Redirection works well for a number of reasons: Users can see that they actually log in on the service's (twitter, facebook, you name it) website. That creates trust between the user and your website (you use a trusted third party to log in), and is also technically secure (as in you don't send the credentials to fb or twitter, thus enabling a man-in-the-...


7

I think that there's no real solution to your problem. That might be hard to hear, but there's no way to gain any security without sacrificing your user experience. Instead, we just need to pick the "least-worst" choice. Using a phone number or credit card number for anything is grounds for an immediate bounce from most users. If you looked at a study, you ...


6

You should ask for the entire password, not just because it is more secure, but because users entire passwords by muscle memory, especially passwords made up of arbitrary characters, or defined by movements across the keyboard. This makes it hard for users to recall characters in specific positions.


6

I would say this post offers a good rational as to why many/most command line programs don't echo. To summarize, it is normally much easier to disable echo, than replace the text, with command line programs.


6

Part of the commonly held belief by technical people is that not having an echo of * makes the password more secure as anyone watching over your shoulder is not aware of the password length - which they would be if they saw the number of * characters. So whether or not the original reasoning were security, the fact that most users perceive not having an ...


6

If you check "standard" login screens, like one Mac OSX or Android you can see that they usually don't rely on any headline at all. That's why I'd go with a simple "Suggested users:" as headline for the user list. In case somebody finds it too big-brotherish, you could add a small explanation on a secondary screen ("Who suggested these users?", or something ...


Only top voted, non community-wiki answers of a minimum length are eligible