Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

New Approaches To Designing Log-In Forms

For many of us, logging into websites is a part of our daily routine. In fact, we probably do it so often that we’ve stopped having to think about how it’s done… that is, until something goes wrong: we forget our password, our user name, the email address we signed up with, how we signed up, or even if we ever signed up at all.

These experiences are not just frustrating for us, but are bad for businesses as well. How bad? User Interface Engineering’s analysis1 of a major online retailer found that 45% of all customers had multiple registrations in the system, 160,000 people requested their password every day, and 75% of these people never completed the purchase they started once they requested their password.

Further Reading on SmashingMag: Link

To top it off, visitors who are not logged in do not see a personalized view of a website’s content and recommendations, which reduces conversion rates and engagement. So, log-in is a big deal — big enough that some websites have started exploring new designs solutions for the old problem.

Is This You? Link

Gowalla’s sign-in form (below) looks pretty standard: enter your user name or email address and your password, and then sign in. There’s also help for those of us who have forgotten our password or are new to the website. In other words, all of the most common log-in user-interface components are accounted for.

The sign-in form on Gowalla.

But Gowalla has taken the time to include a few more components to help people log in with more confidence if their first attempt hasn’t worked. If you attempt to sign in with a user name (or email address) and password that do not match, the website not only returns an error but returns the profile image and user name of the account you are trying to sign into as well:

A log-in error on Gowalla.

Including a profile picture provides instant visual confirmation: “Yes, this is my account, and I may have forgotten my password,“ or “No, this isn’t my account, so I must have entered the wrong user name or email address.” In either case, Gowalla provides a way to resolve the problem: “This isn’t me” or “I don’t know my password.”

The Q&A website Quora8 takes a similar approach, but it doesn’t wait until you are done trying to sign in before providing feedback. Quora’s log-in form immediately tells you if no account is associated with the email address you have entered, and it gives you the option to create a new account right then and there:

Quora instantly lets you know if there are no matching accounts for the email address you have entered.

If the address you have entered does match an account on Quora, then the account’s profile image and user name will appear to the right of the log-in form. This confirmation is similar to Gowalla’s but comes right away instead of after you’ve submitted the form.

If the email address you enter on Quora matches an account, you get visual confirmation instantly.

Instant Sign-In Link

Quora’s log-in form also includes an option to “Let me log in without a password on this browser.” Checked by default, this setting does just what it says: it eliminates the need for you to enter a password when re-logging into Quora. All you need to do to enter the website is click on your profile picture or name on the log-in screen.

Quora’s one-click log-in page.

To go back to the standard log-in screen, just click the “x” or “Log in as another user,” and then you can sign in the hard way: by entering your email address and password.

While one-click sign-in on Quora is convenient, it doesn’t really help you across the rest of the Web. For that, many websites are turning to third-party sign-in solutions.

“Single-sign-on” solutions12 such as Facebook, Twitter, OpenID and more have tried to tackle log-in issues by cutting down on the number of sign-in details that people need to remember across all of the websites that they use. With these services, one account will get you into many different websites.

Sign In Options13
A sampling of single-sign-on solutions.

Logging in this way is faster, too. When someone connects their Facebook or Twitter account to a website, they simply need to click the “Sign in with Facebook (or Twitter)” button to log in. Of course, they need to be signed into their Facebook or Twitter account in order for it to work with one click. But with 50% of Facebook’s 750 million active users logging into Facebook14 on any given day, the odds are good that one click is all it takes.

You can see this log-in solution in action on Gowalla (screenshot below). A Gowalla user who has connected their Facebook account needs only to click on the “Log in with Facebook” option in order to sign in — provided they are already signed into Facebook, of course. If they’re not signed into Facebook, they’ll need to do that first (usually in a new dialog box or browser tab). After doing so, they will be instantly redirected to Gowalla and logged in.

Gowalla provides an option to log in using your Facebook account.

New Log-In Problems Link

But with these new benefits come new problems — usually in the form of too many choices. When faced with multiple sign-in options on a website, people do one of the following:

  1. They remember the service they used to sign up (or that they connected to their account), and they log in instantly. This is the best case scenario.
  2. They assume they can sign in with any third-party service (for which they have an account), regardless of whether they have an account on the website they are trying to log into. The thought process for these folks goes something like this: “It says I can sign in with Facebook. I have a Facebook account. I should be able to sign in.”
  3. They forget which service they used to sign up or if they used one at all, and thus hesitate or fail to log in.

To make matters worse, if someone picks the wrong provider, instead of signing in to the service they’re trying to use, they might end up signing up again, thereby creating a second account. While a website can do its best to match accounts from different services, there’s no completely accurate way (that I know of) to determine whether a Twitter and a Facebook account definitively belong to the same person.

So, while third-party sign-in addresses some problems, it also creates a few new ones. In an attempt to solve some of these new sign-in issues, we’ve been experimenting with new log-in screen designs on Bagcheck.

Our most recent sign-in screen (below) is an attempt to reduce confusion and prevent the types of errors I have just described — admittedly, though, at the expense of one-click sign-in. In this design, people are required to enter their user name or email address to sign in. We use instant search results to match their input to an existing user on the website, so someone needs to type only the first few letters of their name to find their account quickly. This tends to be much faster than typing an entire email address. But because more than one person is likely to have the same name, we provide the ability to sign in with an email address as well.

Once someone selects their name or enters their email address, then their options for signing in are revealed. No sign-in actions are shown beforehand.

Bagcheck sign-in16
The current Bagcheck sign-in screen does not reveal any log-in options until you select your name or enter your email address.

True, in this design people can no longer sign in with one click, because the sign-in buttons are not visible by default. But this may be a trade-off worth making, for the following reasons:

  • We keep people signed in until they explicitly sign out. So, hopefully people will rarely need to go through the sign-in process. Remember: the less people need to log in, the fewer sign-in problems you’ll have!
  • The added amount of effort required to sign in is small: just start typing your name and select a search result, or enter your complete email address, and then click the sign-in button. It’s not one-click, but it’s not a lot of work either.
  • Trying to sign in with an account provider that you have not set up on Bagcheck is no longer possible, because the log-in buttons don’t show up until after you have selected your name. This cuts down on duplicate accounts and confusion over which account you have signed up with or connected (especially on different browsers and computers where a cookie has not been set).

On mobile, however, these trade-offs may not be worth it. Logging into a website on a mobile device by typing is a lot more work than just tapping a button. So, in the Bagcheck mobile Web experience, we’ve kept the third-party sign-in buttons front and center, allowing people to log in with just one tap. It’s just another example of how the constraints and capabilities of different devices17 can influence design decisions.

The Bagcheck mobile Web experience keeps one-tap sign-in options visible.

Since launching this log-in experience on Bagcheck, we’ve gotten a lot of great feedback and ideas for improving the interactions. Many people have suggested using browser cookies to set a default sign-in option for returning visitors. While this might help people who return to the website using the same browser, we’ve seen many more sign-in issues when people use a different browser or computer. In these cases, a browser cookie won’t help.

Another common question is whether allowing anyone to search the list of Bagcheck users by name or email address reduces security. While this design does somewhat reduce the security of a Bagcheck account (compared to our previous log-in screen design), it’s no worse than many websites that let you sign in with your public user name, like Twitter.

And because all Bagcheck profile pages are public, users can be searched for on Google and on Bagcheck itself. Despite this, we’ve seen a bit of increased concern over this same search capability being on the sign-in screen. So, if you’re thinking about trying this design, make sure your profile pages are public, and be aware that people may still be a bit sensitive about it.

We’ve All Got Email Link

Although signing into a service with one’s name may be too new for some people, logging in with an email address is common practice for most. Using a solution that brings together a lot of the ideas outlined in this article, Google’s Identity Toolkit19 and Account Chooser20 allow people to sign in across the Web using just their email address:

Google’s Identity Toolkit allows people to sign in with a number of email verification options.

When multiple accounts have been accessed in the same Web browser, each account is listed as a sign-in option, making account selection easier. If you want to try out this sign-in solution, you can opt in22 on Google’s website or implement it on your website with Google’s Toolkit23.

Selecting from multiple accounts on Google’s experimental sign-in page.

The Little Things Matter, Too Link

The Bagcheck and Google examples we just looked at try to rethink log-in pages in big ways. But not all sign-in innovations need to be so comprehensive. Even small changes can have a big impact. For example, I mentioned earlier that inputting text precisely on mobile devices can be harder than on full keyboard computers. Coupled with obscured password fields, this can make logging into a website on a mobile device a challenge.

Facebook’s mobile Web experience25 tackles this in a small but useful way. If you enter an incorrect password when trying to sign in, the website will change the password field to plain text so that you can actually see your input. Facebook also offers an alternate way to log in, using your email address or phone number (screenshot below). It’s a small enhancement but one that can go a long way on mobile.

Facebook does a lot to help you log in on mobile.

It’s Not Over Link

As these examples illustrate, even the most common interactions on the Web (like logging in) could benefit from new ideas and design improvements. Not every idea I’ve walked through here will become part of all the log-in forms we encounter on the Web — chances are none of them will. But without trying, we’ll never know.

So, if you have some new ideas for signing in or any other Web interaction we’ve come to take for granted, try them out and let the rest of us know what you’ve learned!

Online Resources Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30

↑ Back to top Tweet itShare on Facebook

LukeW is an internationally recognized Web thought leader who has designed or contributed to software used by more than 600 million people. He is currently Senior Director of Product Ideation & Design at Yahoo! Inc., author of two popular Web design books, and a top-rated speaker at conferences and companies around the world. You can follow Luke on Twitter at lukewdesign or by using RSS.

  1. 1

    Most of these techniques would allow a third part application to know that an particular email, person, name … is registered on a website.

    Which totally helps for fishing.

    Or for identity theft.

    • 2

      I agree with you Simon.

      I have recently been creating a secure log in page for my own login page for my own application. If you offer a returned list of people on the name/ email input then you are showing people who have an account.

      However, this is still a nice feature and is a shame that security/ user protection will always be at the top of the list when creating secure applications.

    • 3

      Diego Fernandez

      August 22, 2011 6:16 pm

      Actually the display of the login picture is for security reasons: is to make phishing more difficult. Other technique is split login: first the user name, then show the avatar before entering the password (in that way is more difficult to make a fake version of the login).

      I learn about this technique while talking with an online banking security expert about the usability of login forms and security.

      As other commenters I agree that’s a solution with ugly consequences.

  2. 4

    Surely any service that presents a list of valid usernames at the point of login has just reduced their security (increased hackability) by 50%. I have to say i’m not a fan!

  3. 5

    As a side note to Quora section. By saying “There is no account with this email address” you may also be exposing that there _is_ an account with an email address (when the form returns only a password error) if someone is attempting to login maliciously and therefore halves the amount of information they have to guess.

    This might expose that a person is a member of a website that perhaps they should be e.g. having an account on a sports betting website.

    At (a sports betting website funnily enough) we didn’t show a “your account exists, but you password is wrong” message like this on the front end (because of the risk of ‘outing’ members). What we did do was email the member behind the scenes saying that someone (perhaps themselves) was trying to log into their account, and if it was malicious then to get in touch.

  4. 6

    What if I don’t want people knowing I’m a member of a site and they start typing in the same first name I have? Sounds like a horrible implementation from a privacy standpoint.

  5. 7

    Auto-Suggest is a great feature for something internal or for features that require you to be logged in. Using it as a log-in ‘feature’ is at best a silly practice designed to fake some sense of being a member of a community and at worst a gross breach of privacy, made worse by those that not only display your full name but also your associative profile image.

    Hopefully they have an opt-out option for those users who don’t wish to have their name associated with the website or are otherwise concerned with their privacy.

  6. 8

    I wouldn’t be happy, as a user, if I saw that information like this was made public about me on a site.

  7. 9

    Craig Villamor

    August 22, 2011 3:06 pm

    As Luke says, It’s very interesting to see how context changes the perception of security. The absence of a user search on a site with public profiles would be considered a huge oversight in a product, but when put in the context of sign in it is perceived as a security risk.

    It reminds me of my first time on a ski lift. With the safety bar up, I felt like I was sitting on an incredibly narrow and precarious seat; like I could fall out of the lift at any moment. I hung on for dear life. As soon as the bar came down, I felt as comfortable as if I were sitting on the living room couch. Did the seat suddenly get bigger? Of course not. But my perception of risk was completely changed thanks to a thin little bar placed in front of me.

    Luke, I think this illustrates that even though your solution solves a usability problem, it introduces a perception problem. Sometimes UIs need to be made less convenient in order to communicate more clearly to the user or, in this case, to alleviate fears.

  8. 10


    From a UX perspective, these are all interesting and more user-friendly approaches to traditional login forms. However, some of the examples you list make TERRIBLE security decisions in order to achieve this “simplified” user experience. Bagcheck & Gowalla are the worst in this regard—they’re just begging to be brute force hacked. Here’s why:

    First, both sites tell you if the user you’ve entered is a valid user. Heck, Bagcheck even SUGGESTS users for you. Strike 1!

    But “a public user name (or real name) is public whether or not there is an auto-suggest feature”, you say. “The auto-suggest just makes it easier to log in.” Sure, and it makes it even easier for others to find out your username since it’s all nice and AJAXified (no trial-and-error necessary). With one look at the network inspector, I now have the URL to get your user ID (or whomever’s I want): (urls stripped by comment system)

    Second, both allow a seemingly unlimited number of invalid password attempts without any ReCaptcha or lockout. C’mon, this is web security 101. Strike 2!

    Finally, both password entry pages are accessible via a simple GET request with the user ID as a query parameter. Strike 3!
    Bagcheck: (urls stripped by comment system)
    Gowalla: (urls stripped by comment system)

    Guess how long it would take someone to write a simple Perl script that takes a list of randomly-generated user IDs and hits the above URLs with a set of common passwords?

    These issues can be resolved very simply without throwing away your trendy new login flow:
    (a) Show a ReCaptcha form after X number of failed password attempts
    (b) Make the password entry page a POST, not a GET request. Ironically, this comes straight from the W3C and your former employer’s own “security best practices” document: developer dot yahoo dot com slash security

    I apologize if I came off a bit harsh, but I cannot let insecure practices like these be lauded and spread without educating others about their risks. I hope you understand the severity of these risks and take the necessary steps to protect your users while maintaining your desired UX.


  9. 11

    Jason Featheringham

    August 22, 2011 6:18 am

    These are interesting methods, and definitely improve the experience, but at the cost of privacy. Some of these methods could allow a person to narrow down the list of people they are trying to brute force hack. I would be very cautious using most of these techniques.

    • 12

      Exactly. In the first example shown here, where an image is returned upon entering an existing email address, that will allow the world to know (particularly spammers and hackers) that a particular email address is valid. That is a major security issue if not handled properly.

      An unsuccessful login attempt should NEVER specifically state whether the email or password was incorrect. Rather, it should state that “the username and/or password were incorrect” or something to that effect. That way, someone who may be up to no good, won’t know if anything they’re typing in is actually valid.

      • 13

        I agree with Jason and Jesse. I liked the ideas and thought process about sign-in, but I am concerned about the security aspect of the solutions.

      • 14

        Kage Edwards

        April 12, 2013 9:21 pm

        It’s still a security issue though, as if its returned an account, its evident the email was the one correct.

  10. 15

    I really like this topic since login has become very standardized and I think it’s a good idea to challenge that convention. But I’m afraid I have to agree with some of the other comments that a number of these techniques appear to present security issues. The two things that jumped out at me were the ability to possibly discover a users real name by entering a random email address, and connecting other account logins through Facebook.

    I’m not a security expert, but it seems like hackers could easily exploit both the free information (let’s see what personal info I can find on Luke Wroblewski online. Oh, your favorite color is blue, hope that’s one of your security questions), and connectivity stemming from using your Facebook account to access other online accounts (in other words, if someone hacks one account they could possibly access them all before you realize it, thus causing even greater damage). Once again, I’m no expert, but some of these concepts seem risky.

  11. 16

    ID theft risk is in part a function of how well users understand login processes. Responsible users know they should log out of sites logged into, especially on a shared device.

    Using an umbrella login for many sites (but not all) increases login management complexity. Logging in logs you into the ‘meta’ identity, but logging out of subscribing sites does not. This requires users to remember to log out on 2 levels or risk exposing all content accessible via their meta identity.

    It’s also a little scary to offload security considerations to a third party who will bear no responsibility in court.

  12. 17

    Adam Patterson

    August 22, 2011 7:31 am

    I don’t mind using the Facebook and Twitter logins if the site I’m logging into needs access to those services.

    But I avoid using them for unrelated sites/apps.

    We had a discussion around using Facebook, Twitter, and Google as options for our web app but came to the conclusion that people might get the impression that those services might gain access to their Data in our app (legal documents).

    I think people need to stand on their own two feet and let the user take responsibility for their own credentials. If your product is good people will take the 30 seconds to join.

    • 18

      How about this idea:

      Step 1 – The user connects to.
      Step 2 – The user enters his/her e-mail address.
      Step 3 – The user access his/her e-mail account and then opens up a link which authorizes the session and returns a special key to the user (this is the part that could still use a lot of brainpower, the key should be unique and hard to generate, but comparably easy to remember, it’s a real toughie).
      Step 4 – The user can now use this special key (or “access pass”), on every site connected to this centralized login-system.

      An important part of this is that whenever a user enters his/her contact information on any site (this would only be necessary if no information can be found in the login-system already), this information is stored in the login-system.

      It wouldn’t take long for extension developers to spread a small plug-in which can help you keep track of the once-or-twice inevitably inescapable hard-to-remember access keys.

      The similarities are really close to that of “Login with Facebook” or OpenID, but the idea is to eliminate the usual email/password scenario. I’m tired like a mother(…) not simply having a universal key to go where I need to go and let me do my own thing. The whole authorization process is in this way transferred to your e-mail service, like, for instance, Google’s Gmail. The generated “access pass” can be used on your smartphone, laptop, workstation, a random public computer and anything else you might be standing in front of with access to the Internet.

      • 19

        Check out LaunchKey. Widget gets integrated to web site. All authentication is done via mobile phone.

  13. 20

    AND. How hard would it be for a malicious site to create a fake version of this login system where a popup visually identical to Google’s collects meta identities? Ooops.

    If you are going to whip out the master key, it should be something you do securely BEFORE you start visiting

  14. 21

    Mário Almeida

    August 22, 2011 7:34 am

    I’ll just repeat what has already been said, but…

    Looks nice, but all these examples lead to little or no security. Login forms should never state which field is incorrectly filled.

  15. 22

    cancel bubble

    August 22, 2011 7:48 am

    Everyone has already said what I came here to say: Privacy and security. The auto suggest on login is especially bad.

  16. 23

    complete security compromise for what? Convenience? I don’t think so!

  17. 24

    To everyone calling out security issues… a site with public profile pages by default has a searchable index of members. You can search that list through Google, Bing, the site’s search feature, etc. This is NOT something new being added to just the log in feature.

    A site with public user names has the same level of security. You can search by user names using any of the methods above. These sites allow logging with username and password.

    So please tell me what the “security compromise” is here??

    • 25

      I think security concerns vary according to the nature of the site. But publicly associating real names, email addresses, and avatars by default is not a good idea. If people want to expose themselves to whatever risks may come from it, that should be their call. But it has been shown that a screen cam and facial recognition software can identify random people reliably from public facebook profiles.

      IMO this meta ID approach is not very secure. It’s better to have it sandboxed in the browser. As it is, it requires the user place a lot of trust in any site that uses it.

      On your Bagcheck site, for example, you have this language:

      “This application will not be able to:
      Access your direct messages.
      See your Twitter password.”

      IMO, that shouldn’t be necessary.

  18. 26

    When a login fails, my understanding is that security best practice prescribes to not tell the user (potential hacker) if the email address / username or password caused the login to fail.

    Some of the other sites mentioned above do break this security rule as well but you are making this information more easily and explicitly accessible, which I think causes the above comments.

  19. 27

    This is an excellent article, but you don’t entirely cover one point which is pretty important that I’d love to hear your thoughts on. How best to authenticate and identify users? This is actually a very difficult problem to solve. I can see that you have approached it with the management of user accounts + ‘integrate’ it with a few providers. But that presents one major failure with OpenID, which is the issue of merging accounts and email address changes. How do you solve that problem in the least confusing way?

    A question was recently asked on Quora which details this point further:

  20. 28

    @Ian what information? Your name or username? Cause that’s what Facebook, Google+, Gowalla, Quora, Twitter, Bagcheck, etc, etc do. They have PUBLIC profile pages. You can choose what you show on these pages but joining the service creates a public page for you. That’s what happens when you sign up (which is your choice).

    @Kevin that’s still a good best practice but in the case of a service like Twitter (or any service with public user names that allows you to log in with username & password), it’s a moot point. Anyone can see there is an account with the username by searching, browsing, etc. on the site. So the only part that’s unknown is the password.

    Same thing is true for Facebook. Type an email address into the search field at the top of any Facebook page and you will find the user with that email address on the site.

    Just between the Twitter (200M accounts) and Facebook (750M accounts) examples, there’s 950 million accounts in this “insecure state” you are concerned about.

    I’m NOT saying public profile pages are for every site on the Internet. But for the sites that have them… they already have the level of insecurity you are describing. It is NOT an artifact of any of these log in page designs.

    Hope that clarifies things?

  21. 29

    For those of you concerned about your privacy and security, I take it you completely avoid Facebook, right?

    It’s amazing how so many more are concerned about username auto-suggest than those concerned about using a public name as a username. It’s the same thing people!

    • 30

      Actually, I do not use Facebook due to the whole privacy issues and repeated security failures they have had over the past few years. Also, the fact that Zuckerberg has also said that if he were to do it all over again, all data would be public. All data.

      I’m going to correct myself and say that I do have a FB account, it’s a fake account that I log into once every 2-3 weeks so I can see why my teenage niece is up to.

      I’m in agreement with most of the commenters, these login methods are a step back in terms of security at the cost of improved convenience. I think that if we take what Luke was saying and tie it with some captchas and IP blocking (after x attempts), then it would be a step in the right direction.

  22. 31

    @Paul “It’s amazing how so many more are concerned about username auto-suggest than those concerned about using a public name as a username. It’s the same thing people!”

    Correct! A public user name (or real name) is public whether or not there is an auto-suggest feature. The auto-suggest just makes it easier to log in.

  23. 32

    I was impressed with the way Friendfeed handled the delegated login case. It allowed Facebook, Twitter and Google login (as well as email). If you picked the wrong one, it realised this and prompted to add FB to your Twitter account (or whatever). As this also merged in the people you were following it was extremely smooth.

  24. 33

    Great article.

    There are problems with the desktop version of the Bagcheck log-in. It’s too smart for its own good.

    For instance, if you use smartkeys or a textexpander to automatically type your email address and/or user name, you can never sign into Bagcheck. The predictive name list dropdown won’t load because your type isn’t manually entered, thus there is nothing for the predictive script to interact with. Instead, your email address appears instantly in the email address field, but nothing else happens; the ENTER or NEXT button doesn’t load because the system is engineered for manual typists only. It doesn’t know what to do with type that automagically appears in the address field. It just stops, there’s not error message, you’re in limbo.

    And it’s not just power users with text-expander utilities who can’t log in.

    If you manually type your name and your name is *common* but you aren’t a *famous* or favored user, your own name never loads in the predictive dropdown. Say your name is Tim Smith. You type Tim and Tim Berners-Lee or Tim O’Reilly will show up, but you won’t.

    I love the ingenuity of Bagcheck’s login but it needs to work better for all users, not just for “normal” users with unpopular names who manually type their email address.

  25. 34

    This was entirely the wrong forum for me to have logged these problems with Bagcheck. I do not mean to hijack the thread. Please carry on.

    The article is wonderful.

  26. 35

    It seems like the three log-in issues you’ve outlined stem from people simply not being used to the process of signing in with other accounts or they’re just not as technically savvy. Personally, I like the direction the log-in process is moving towards and we’re just still in the adoption phase, I can see more people getting used to it and accepting how it works.

  27. 36

    * I meant to say:
    “(b) Make the password ENTRY page a POST, not a GET request”

  28. 37

    Showing a list of people with photos while you type your username in bagcheck is pure information disclosure and is probably illegal in a good number of countries! It not secure either!!!

  29. 38

    @Meketrefe go to Facebook. Type someone’s name in the search box at the top of the screen. That’s illegal in a good number of countries?

    @Mike your strike 2 & 3 are valid development points and should be in place. I agree
    Strike 1, I disagree is any different than a site with search that includes user names. Most sites even have APIs for looking up user names. (also see my comment above. nice & AJAXified on facebook as well).

    @ Craig, three comments from Twitter discussion on this topic that are applicable to your points:
    “in security-related UI, perceptions (and misperceptions) matter even more than in regular UI. lots of fear & misinfo out there.” -@jreffell
    ” to be fair security UI concerns are valid because the user perceives them, not because the designer’s logic refutes them.” -@jaysondb
    ” I’d say that many designs have created artificial/wrong security perceptions. See password field and keylogging.” -@lukew
    “i agree with you both! also see: password rules that make you work hard but don’t really add security …” -@jreffell

    @zeldman fair point on people using “text-expander utilities” that’s a consideration worth looking into. Also password managers like 1password don’t do very well with anything but a standard login box (3rd party sign, search UI (like Bagcheck, Google email login, etc.)

    • 39


      – my Facebook display name is different from the e-mail address used to log in.
      – on Facebook, the user has a CHOICE to hide the account from being displayed in the search box to everyone, or everyone but their friends. In this case, you’re showing it to users that haven’t even been authenticated.

      You seem to completely miss the point that most login forms on this planet are so complex and hard because of security.

  30. 40

    I love how a lot of these comments scream security issue just because your showing public user-names during the sign-in process, as Luke has stated major websites have done this for years, it doesn’t make it less secure as long as your validation checks hold true in the back end (This includes brute force prevention techniques).

    I think a lot of people believe what is simply not true in the real world for instance just a few months ago in my college class we were talking about Facebook and this girl in my class said her account got hacked and it was super easy to hack Facebook accounts and when I told her she was completely wrong she was rather surprised.

    I told her hacking Facebook is tough, they got top of the line security, there isn’t a lot of people that will hack Facebook, I said 95% of people don’t hack Facebook to gain access to a user account they hack the individual via key-loggers and other malicious software, its much easier to create a windows virus that scans for keystrokes then it is to sit there and hack some random persons Facebook account.

    The mis-conception happens when the unknowing user phrases there frustrations by saying “They hacked Facebook and gained access to my account” when most of the time they just didn’t log out of Facebook on there computer or they had a key-logger installed.

    Those are just small examples but my overall point is it doesn’t reduce your security when you show public user-names via a login form it just gives the illusion of reduced security. Any real web developer will take the time to put in place a ton of validation checks on the back end systems to make sure its really secure.

  31. 41

    Many people above have quickly realised what the article’s author didn’t – showing a user (see: potential attacker) that an account exists immediately makes your site – and your users’ personal information – easier to attack. Usability and security should not be mixed. To everyone saying this is not a big security concern and that this sort of thing happens elsewhere anyway – this doesn’t make it a good idea! If I need a username and password combo to hack someone’s account I’ve got a tough time ahead. If I know a valid username my job is significantly simpler. Why make it easier?

    • 42

      Your absolutely right but the point were trying to make is that even though you provide the potential malicious software or user with one piece of the puzzle it doesn’t make it all that much less secure as long as your back end security protocols are built correctly.

      The best bet is to use a different public display name then the actual login name and then still ensure your back-end security is valid making it that much more secure but at the end of the day if you have built your security protocols correctly using the public display name as the login name really isn’t a huge thing to worry about.

    • 43

      I also should of mentioned that I do believe if your using an email address you probably don’t want to show the email address to the world for several reasons, one is someone could collect them and spam your users and two is they could spam your users with clever email downloads that would then install a key-logger onto the users operating system, eventually giving the hacker easy access to that account on your website.

      Honestly there are so many things that you can do to keep the same functionality your saying “should not be mixed” with the designs that Luke has mentioned in this post. It just requires being clever and thinking things through with your team.

  32. 44

    It is always good to challenge existing ways, so I find this article useful. Still, I have a few comments:

    – If you speak of singin, you must also consider signout. You want to make it easier for users to signin by letting them have long sessions, so that the need to signin becomes less. That’s fine in itself but please consider the situation of users on a shared device. If these users are not that web savvy, they likely forget to sign out, and you have a major breach. This is why every major service has expiring sessions, with a checkbox to persist the session. Yes, it’s another choice, but an important one.

    – Another commenter in this thread is saying that the name lookup suggestions are not a security breach, because Facebook is doing it as well and if you have a solid back-end in place, it is no problem. Here’s my take:

    —- Two wrongs don’t make a right. Facebook is about the most privacy-invading web service in the world. Just because they are doing it, doesn’t mean you should. Also, just because users naively share personal info all over the web, doesn’t mean you should assume that data isn’t worthwhile protecting. Users are ignorant, remember?

    —- You’re not Facebook. They probably have dedicated security teams, anti spam teams and millions to spend on the problem. You don’t.

    Having said that, here’s a very simple tip to make your back-end for signin handling slightly more secure…


    Insert a timed delay after each login attempt. Set a time of between 1 and 3 secs. User’s wont really notice, yet for a bot a brute force attack becomes incredibly slow.

    • 45

      “Insert a timed delay after each login attempt. Set a time of between 1 and 3 secs. User’s wont really notice, yet for a bot a brute force attack becomes incredibly slow.”

      A bot doesn’t have any problem with issuing a second (or third, or hundreth) request without waiting for the result of the first attempt to come in.

      Such a method is only useful if you are able to serialize requests.

      It’s also worth noting that this allows an attacker to keep a httpd process dedicated on your server for three seconds, allowing for a very easy DoS attack.

      • 46

        Which is why I said “slightly” more secure….

        And as for DoS attacks, if you’re a target, you’ll go down no matter what.

    • 47

      The best measure I have found for DoS attacks for my CMS, is after X failed attempts I restrict access to the site for x amount of time. So, if a BOT was attacking me, or a person they would have to wait for X amount of time or reset the router to renew the IP address.

      The only way around this, would be to forge the IP address which can be done.

      @Luke I really like the idea, but maybe take it one step further: With my bank login, you enter your username, it then takes you to a second screen with an identifying image that I have selected/ uploaded and I type in my password. It is an extra level of protection.

      Another suggestion would be to force users to create a username and NOT use their firstname.surname.

      As Ferdy said, 2 wrongs do not make a right, being a web developer, you should strive on being the most secure, but then every one should remember, for every clever person creating the best security system, there is another person equally or more clever that can break that security.

      If it’s man made, it can & will be broken as history has taught us….

      Again, I really do like the sites…

  33. 48

    Manuel Strehl

    August 22, 2011 11:23 pm

    Mozilla experiments at the moment with a new concept called BrowserID:

    In the long term it is aimed at putting identification in the browser itself, which, if you think of it, makes perfect sense.

  34. 49

    Personally I’m a little torn on this issue. I love it when a site makes that login process easier, I’ve got more accounts on more sites than I could ever remember, but generally speaking I’ve never had a security issue. Am I web savvy? Yea, but I think users really need to become educated. Even with sites such as Facebook, I don’t care if you’re on my will, I’m not telling you my password, I’m not sharing the answers to my secret questions. I find a lot of people just don’t protect their data. My public profiles I have yet to have a problem, but it’s cause I make it hard to have a problem in the first place. I use different email addresses and a multitude of passwords that sit in my reservoir of knowledge for each service. I’m not 100% secure and would never claim that, but really I do think the end user needs to take some responsibility.

    Will it ever get to that point? I doubt it… there are always uneducated people, and there are always idiots and it hasn’t changed since the beginning of mankind. Also if a user really wants your content, I think they’d take the extra time to track down their account. I’ve spent hours tracking down an old WordPress account just because I didn’t want the blog showing up on Google anymore. Little excessive, but for a site like Amazon or Ebay or whatever, I’d rather get my information back and use my account than create another and leave my credit card or other private information just floating there.

  35. 50

    Nice one!

    but link

    “Web Form Design: Filling in the Blanks”
    Everything you need to know about designing effective and engaging Web forms.

    doesnt work :(

    • 51

      Francisco Inchauste

      August 23, 2011 5:09 am

      @Milan The link does work, however it appears that LukeW’s site (where it links to) is currently down. I’m sure it will be back up soon. Thanks!

  36. 52

    There are so many negative comments on this thread from people who seem to have never actually run a web server themselves, or been involved in pen testing.

    1. Brute force attacks – almost non-existant in proper web apps. Brute force reliess on carrying out a huge amount of attempts. Something simple like fail2ban practically eliminates that (but obviously you’d use other things as well). Every hacked account I’ve had to deal with has been due to social engineering, or PC malware, software vulnerabilties. Not a single one attributable to brute force password cracking. Brute force is for breaking local protection – Windows passwords, password DBs, etc. But do note that public profiles do make social engineering easier.

    2. Username name gathering – Using a simple bot I could probably gather all the public profile names from a site in under ten minutes. Any half-decent pen-tester will use a local DB of usernames, so why would a malicious hacker or script kiddie waste their time with some login form username revealing.

    I’d suggest those of you who are concerned do some research on pen testing and app security.

  37. 53

    Regardless of the debate as to whether showing list of members is a security fail or not.

    It is most certainly a privacy fail. Large sites doing it doesn’t make it right.

  38. 54

    What irritates me the most is websites that have specific requirements for the password (e.g. needing to include both letters and numbers, both uppercase and lowercase letters etc). I often end up having to come up with variations from my regular passwords for these sites, and when I return, I can’t remember what variation I used.

    A simple solution to this would be to just include the password requirements as a note on the login form so I can figure out what password variation I’m using on the site. So far, I’ve only seen one site that does this (it reminded you of the password requirements after a failed login attempt).

    • 55

      Chris Raymond

      August 23, 2011 7:27 am

      Yes, isn’t it great to not TELL you in advance what the requirements are, like it’s a state secret. Let’s aggravate people before they even join your site!

  39. 56

    Chris Raymond

    August 23, 2011 7:27 am

    The Envato sites drive me up the wall: I have an account at one of their subsites, it takes my money. But it puts me through log-in hell every time, insisting I enter unreadable captcha codes even when I use my correct login info. It’s at the point where I just may drop my account there.

  40. 57

    @Paul August 23rd, 2011 12:31 am
    @bizzyLabs August 22nd, 2011 6:28 pm

    make great points. But as this thread shows there’s a lot of misconception about privacy and security out there. Regardless of whether or not these concerns are valid, they need to get considered in a design. As @jaysondb said “to be fair security UI concerns are valid because the user perceives them, not because the designer’s logic refutes them.”

    Hence my original statement in the article:
    “And because all Bagcheck profile pages are public, users can be searched for on Google and on Bagcheck itself. Despite this, we’ve seen a bit of increased concern over this same search capability being on the sign-in screen. So, if you’re thinking about trying this design, make sure your profile pages are public, and be aware that people may still be a bit sensitive about it.”

    As all these comments re-iterate. This is certainly true! :)

    • 58

      Fascintaing article, more for the comments and feelings about security than anything because it highlights something I also instantly felt when I saw your Bagcheck login form autocomplete names.

      The feeling of implied lower security.

      As you mention, the usernames of people are openly available on the site as they are for Twitter users etc and there’s some logic to it being no less secure but strangely the Bagcheck login immediately gave me a bad FEELING.

      To my mind, we’ve always been conditioned over the years to make sure nobody is peeking over our shoulders when we log into sites etc and psychologically the autocomplete dropdown was doing a virtual equivalent for some reason. I simply felt uncomfortable seeing what should be a private form displaying names that weren’t mine despite the various benefits you mentioned.


  41. 59

    Completely aside from privacy and brute force stuff, IMO OpenID has issues.

    A master key should not be made available for theft. OpenID amplifies the chances it could be stolen since you are basically handing it out to a lot of other people to unlock the door for you. In the past I have declined to create accounts on sites that require use of an OpenID. I guess you could create a dummy ID that has no access to anything of consequence and use it with little risk, but that diminishes the simplicity angle.

    Even with a reliable 3rd party, it probably doesn’t feel secure to the average user. Why should you be telling some 3rd party how to log into your facebook account?

    Other great identifiers guaranteed to be unique and widely held are SSNs and credit card numbers. Would you want to be using those as an OpenID? Probably not.

  42. 60

    There is a slight difference (whether it’s of much consequence for security or not is debatable) between being able to find out whether a particular user is using a particular service, and exactly which email address that user has used to sign up for that service.

    For example, a public profile would tell you that John Johnson has singed up for that service.

    Depending on how error messaging is handled on the form, the message can not only tell you that John has signed up for that service but that he has signed up using this particular email address.

  43. 61

    Addedndum: Of course, assuming that email is used in place of a username (like Facebook; standard practice today anyways).
    And assuming the site doesn’t have a publicly searchable directory that includes searching by email (unlike Facebook)…

  44. 62

    The only problem I personally have logging in with Facebook or Twitter is giving those sites ‘too much’ access to my personal information and sites I browse. I personally never choose to log in with third party sites. This also affects commenting on some blogs because you can only leave a comment if you connect your Facebook or Twitter account.

    Interesting discussion to have validation during your sign in though.

  45. 63

    I agree with many here. Some of these methods, while looking pretty, are sacrificing quite a bit of security.

  46. 64

    One thing to keep in mind is the emotional impact of this login process. Regardless of the objective security or lack thereof, if there are this many comments and concerns about perceived security issues, then the technique may be streamlining efficiency at the expense of the feeling of safety.

    Just as I would be wary of a storefront that looked suspicious (even if it wasn’t), the mere perception of an issue may be an issue onto itself.

  47. 65

    It’s well established that while people talk about privacy and security their behavior contradicts these concerns. “A protest group titled “Facebook! Fix the Privacy Settings” drew a mere 3,400 of more than 350 million users, less than one-thousandth of 1 percent.” – CNET.

    So if we can get beyond the “emotions” (read: FUD) of security, what data supports the idea that more progressive approaches to sign in/sign up put users at increased risk?

  48. 66

    @Tim -good points. These comments have certainly made the emotional part clear :)

  49. 67

    wow… what a naive view on the topic w/o a conception of basic security (instant sign-in) and privacy (all the let-me-guess frippery) issues.

    hopefully, these techniques will never establish resp. ever will be limited to websites people commonly don’t care about the autonomy of their (personal) data.


  50. 68


    You are really missing the business perspective on this. As far as I’m concerned, I have to deal with it for years now, and clients / standard users are really beyond these problems…
    > ” will be limited to websites people commonly don’t care about the autonomy of their (personal) data” …well, it’s a LOT :D. i’d say around 90% internet users… not bad.
    > It’s a very seductive approach as it’s improving the UX in terms of speed access…and when you’re launching a new stuff you kinda need to still time !
    > And seriously, the security issues you’re mentioning can be easily secured

    I’m not saying it’s the only pov, but – unfortunately – the one with the most power.

  51. 69

    I have to agree with most of the other comments, displaying user-image to help people verify its the correct login is like leaving a note under the doormat saying what neighbor has the key.

    If the system had some way of displaying random images on false names (from a huge database), to avoid being able to notice fakes vs. real. then i could see the point, but still it would create a huge security risk. That way the real person would know if its correct, but not an outsider.

    There is a reason why most login errors says: Username and / or passord did not match. To avoid being able to tell if its a real username.

    But then again, alot of services has usernames as displaynames, so the only unknown is the password.

  52. 70

    Realize I’m a bit late to this conversation, but I’m noticing a glaring error — yes, I can search on Facebook by my name to see that I am a member, but my name is NOT my login, the primary email address I associated with my account (which I can freely hide from anyone else via privacy settings) is. The auto-suggest feature on Bagcheck is auto-suggesting a LOGIN.

    Yes, I realize that Twitter also allows the username as login, but that doesn’t negate the security issue, it just means that Twitter has the same security issue your Bagcheck site has.

  53. 71

    I understand the security/privacy issues here, but I think there’s another angle to look at it… if a service isn’t critical/security-important, do we really need such strong login credentials?

    We started seeing people adding checkboxes for changing the password box to plain text, but what if we went one step further, and maybe even not require a password, or use some other memorable thing as the password-equivalent?

    For instance, on a shopping list app I’ve used between the web and android, it was a simple ‘shopping list number’ which was needed, without any login details. Yes, this might mean someone could randomly guess my list’s number, but what have I lost? Someone now knows I was planning to buy shampoo?

    I think people need to start looking more closely at the usage of service before defaulting to having their own login unique credentials. I hate it when I can’t have my ‘normal’ username on a service because someone’s already taken it (rare, but still happens), it makes me really consider whether I want to use the service at all, and I’m not keen on logging in with my email address because I use unique email addresses with each service I sign up to.

  54. 72

    this is an excellent article!
    i enjoyed reading it and most of the comments below
    it definitely brought up many questions, concerns, and thoughts

    its unfortunate that we cant please everyone. if someone wants higher security with logins, other complain that there are too many steps to reach that point. if someone asks for quick and most convenient way to login to your account, others complain that security risk is too high.

    the issue here is definitely that all these examples sacrificed some part of privacy by making the login process less painful and more convenient (for users or for “hackers). however, its difficult to solve this kind of problem today since we now live in a world where public profiles, sharing, connecting is “in”

    maybe we should step back and realize that we cannot have both. if one is gained other is compromised.

    as designers, maybe we should be asking what is more important for the users for these websites? is it the user’s security or a quick way for them to access their account?
    if security is the important factor then the user of that website will be responsible and remember their account name and password (we never see bank websites asking if we want to connect to facebook or our email)

    if its the convenience the website needs (such as social networking sites) then users should understand that by connecting through mails, facebook, or twitter, or any other “shortcuts” it may cost them some privacy.

    at the end, its user’s decision to know which part they will compromise

    wherever the priority lies, we should focus on that priority.
    either making the log in process most efficient in security OR convenience.
    we cant have it all.

  55. 73

    Thanks for the insight. Also, check out WebFinger (I don’t know if we can start using it in webapps yet)

  56. 74

    I enjoyed the article and all the discussion very much. I’m currently on the lookout for some effective signin solution for a niche e-commerce website, and one of the key takeaway point I’ve learned from here is that probably none of the described signin methods are a good fit when it comes to e-commerce websites.

    This being said, I would appreciate any suggestions regarding some login best practices for e-commerce websites. Thanks!

  57. 75

    James Harry Simons is at one of the most successful hedge means managers of all time. His company, Rejuvenation technologies, is many times drunk on the investment capital rankings. Simmons is also story of the riches handcuffs in the planet with a net quality of 8.5 billion dollars. His business relies on the blue blood of the analyses his employees make. A lot of them sustain Ph.Ds in mathematics, physics and other fields of study and secure paltry or no practice in finance. Their chore is to base models that help the company predict amount changes of different securities.

    Simons is a recent MIT- cultivated mathematics professor. Like some other assets founders he didn’t bring into the world a penetrating experience in finance before starting. But he knew that his schooling of statistics and his make a proposal to of trading could be a potent competitive dominance in the market.

    His approach to management is also unquestionably captivating and refreshing. He organizes a weekly convention with his researchers. The picture is to parcel as uncountable ideas as possible. And they do because their remuneration depends on the profit of the unreserved fund. They drink a great incentive to join forces and communicate. It’s a collective aptitude oriented kind of organisation.

    Set off d emit’s make a muster of what tools James Simmons misuse:

    – An unlatched milieu

    Everybody knows what others do. Everybody can access the train’s resources.

    – Shared ideas
    The weekly meeting is precise stirring after researchers who can liken their findings with others.

    – A compensation based on the undiminished inflexible profits
    Employees share their ideas because they identify that resolution not not emoluments them but also others.

    This kind of direction can be outstanding for every fellowship but hedge funds seems the whole task to fulfil it.

  58. 76

    Great article :-) I am working on a design for a log in box and my case is a bit different than seen else where. Our members can either login with member number and zip code OR username and password. We have a usability issue here because some (not manye hopefully :-)) would think that you could login with fx username and zip code which is not possible.
    The challenge is that I would like to show this without over communicating through a simple design. I am thinking fx using two colours – one for each option there by showing which options are tied together. Have you designed any solutions like this or could you elaborate on what is best practice in a case like this?

  59. 77

    Ahh the age old battle between Security and Usability.

    I hope in the future that we arrive at these conclusions:
    – Obscurity is not security
    – Security problems most popular in the news (and in Congress) are the least common in reality
    – Current forms of security don’t work for people and the data proves that
    – Most implementations widely used only provide the perception of security
    – Nothing is uncrackable or unhackable

    – Usability is usually more important than security
    – Security need only be sufficient to demoralize malice, while usability must succeed in actually enticing interest in an unappealing activity (luring is more difficult than impeding)
    – When we make more usable functionality quicker to implement (one line of code) then developers will welcome it
    – When we prove with data that many threats are not reality and security is often overkill then employers can feel good about tipping their investment in favor of usability

    Currently we have a lot of fearful perception and “what if” corner cases polluting the landscape. Getting consensus on this topic doesn’t easily happen right now. Security is entrenched in technology and that point of view is what wins most often, especially in the States.

  60. 78

    And this is what happens when you allow designers to “design” your security to look pretty.

  61. 79

    As I site possessor I believe the content fast payday loans matter
    here is rattling wonderful , appreciate it for your hard work.
    You should keep it up forever! Good Luck.

  62. 80

    Natural Shop is an E-commerce HTML design designed for online stores selling cash conscious, organic, spa & beauty related products.


    Unlimited color techniques, simple to apply using the exterior color stylesheet provided
    Completely sensitive, suitable with iPad, iPhone etc
    Search engines typeface integration
    Product pages with flexslider
    Search engines Charts and Reddit Completely Integrated
    12 PSDs included
    To download this shop template go to ->

  63. 81

    Arnav Chakraborty

    February 7, 2014 8:11 am

    I want to know how to make a login form using HTML 5, and how to make users log in using other accounts as well.


↑ Back to top