Menu Search
Jump to the content X X
Smashing Conf New York

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. upcoming SmashingConf New York, dedicated to smart front-end techniques and design patterns.

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.

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 Quora4 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” solutions8 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 Options9
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 Facebook10 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-in12
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 devices13 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 Toolkit15 and Account Chooser16 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 in18 on Google’s website or implement it on your website with Google’s Toolkit19.

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 experience21 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
SmashingConf New York

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf New York, on June 14–15, with smart design patterns and front-end techniques.

↑ 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

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

  6. 8

    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.

  7. 9


    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.


  8. 10

    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.

    • 11

      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.

      • 12

        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.

      • 13

        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.

  9. 14

    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.

  10. 15

    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.

  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.



↑ Back to top