Tag Info

Hot answers tagged

37

You have to go with the first option (stating that the "username or password is invalid"), and this has nothing to do with security. Let's say that I usually use JohnGB as my username, but on your service someone else has that username, so I use JohnGB123 instead. Say I've then forgotten my username and I enter JohnGB as my username, but use my correct ...


31

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.


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


23

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


22

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:


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


15

I think currently users are more comfortable with just signing up on site, however that's mainly because that's what most websites do. If done right OpenID and OAuth can work very well. The way StackExchange does it is particularly good. Explain what it is, show that if you have any of a certain type of account can you just press the button, and also what ...


15

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


13

I'm going to give some advice from a Security standpoint + UX. I wouldn't sacrifice either one for the other. Have both. There's an important question of secure practices in your question. The Best Practice from a security standpoint is to not identify which entry was invalid, and have a generic answer. Let's ask What Would Google Do and take Google's ...


10

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


9

Usernames provide a "face" to the world. They're great on forums, etc. to hide the identity of the poster, or allow some personalization. However, for the purpose of logging in, e-mail seems universally better. Most sites I've seen with usernames have a "forgot username" button right next to the "forgot password" button, which should tell you why :-). For a ...


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


8

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


8

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


7

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


6

Is it necessary to interrupt the user while they're in the middle of something? I think it would be better to wait until the current step is done. Two ways you can do that: Wait until they submit the form. Require authentication on an interstitial page, before continuing to the next step. Add the authentication to the bottom of the form.


6

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


6

Although I applaud your lateral thinking, there are some possible issues to consider. The first is that if you have any delay with your mail sending, many posts simply won't go through. Also, if someone is browsing your site without access to their email (yes there are still people without webmail), they will not be able to post. Besides those ...


6

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


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


6

We used social plugin for couple of our products for login. To answer your first question, the simple advantage is that the user need not enter his credentials every time he/she signs in to your app. Most of the times the user is already logged into FB / google etc and can use the same to sign into your app too. A large percentage of users turn away when ...


5

The problem with email addresses is that they are longer and require @ which make them harder to type. Personally I prefer usernames because it makes my life a bit easier.


5

Standard security practice is not to divulge anything about the process while it's in progress. This is because it aids unauthorised attempts to access the system. This may not be a particularly necessary consideration for a message like "You have two attempts left," but never tell the user how long the account will be locked out for. It gives away too much ...


5

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.


4

You can combine several methods: The aforementioned IP authentication. Store information in a cookie or session. Measure number of "same" votes within a very short time period (although these you can just mark as suspect) Each is easily overcome for those who know how, but the question, like Dan Petker said, is how important is the vote? Alternatively ...


4

Well, as for an alternative user might understand you could maybe try to combine the text field with the dropdown and autosuggest. So you have a textbox with autosuggest and a drowdown arrow beside it. If you click on the arrow you see all user names, if you start typing the list will be reduced to the possible user names. if you do not want to add a ...


4

Bagcheck.com had an interesting take on this issue. http://bagcheck.com/blog/02-design-solutions-for-new-log-in-problems They realised that offering multiple social id login methods is counter productive if the user account isn't actually linked to those social ids. Thus, offering a "Login with Facebook" option when the site only knows about my Twitter ...


4

It's pretty much the same as encouraging people to do anything. Why should they care? So you start looking at psychological motivation and you discover incentives. That's really what it boils down to, and you've already referenced some good ones in your own answer. Here are some situations when I'll care about authenticating (or doing anything you want me ...


4

You could remove the third step completely, unless you have some way that the user will be able to come back to your app once they've finished on LinkedIn. Though I understand your app is not LinkedIn itself, you are still using the API from LinkedIn so you are still using their services. Have a look at the example below: Introduction gives context by ...



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