Skip to main content

Hide/Show Passwords: The Missing Plugin

By Tyler Sticka

Published on June 3rd, 2013

Topics

It’s easy to take the “masking” of passwords (replacing characters with ••••) for granted. As Luke Wroblewski documented last November, this practice increases login failures while providing little-to-no security benefit.

Here’s the alternative Luke and his team built into Polar:

By default Polar displays your password on our Log In screen as readable text. A simple, Hide action is present right next to the password field so in situations where you might need to, you can switch the password to a string of •••• instantly.

Similar patterns have also popped up in the LinkedIn app and Internet Explorer 10.

We wanted to try it in a hybrid mobile web app we’re currently building, but couldn’t find any open JavaScript implementations that were touch-optimized. So we made one.

hideShowPassword is a jQuery and Zepto plugin for… wait for it… hiding and showing passwords. Give it a whirl!

The coolest part about this plugin is the “innerToggle” option. When true, it will create a nifty hide/show control you can style as you like. It even maintains the input focus when tapped in a touch browser.

You can get the plugin or view the source on GitHub (also a great place to report issues or contribute improvements). We hope you dig it!

Permalink to Update (March 21, 2014)

Update (March 21, 2014)

Check out Version 2 of hideShowPassword!

Tyler Sticka has over 20 years of experience designing interfaces for the web and beyond. He co-owns Cloud Four, where he provides multidisciplinary creative direction for a variety of organizations. He’s also an artist, writer, speaker and developer. You can follow Tyler on his personal site, Mastodon or Bluesky.

Comments

Jason Grigsby (Cloud Four Team Member) said:

Tyler, this is fantastic work. Thank you for doing it!

However, you undersell the challenges of getting the innerToggle to work on iOS.

For those who haven’t tried to build something like this, it was a tricky task to tap on that show/hide element and not have the keyboard go away on iOS.

There is a bunch of intelligent design in what Tyler has done to make sure it works as you expect. Even if you roll your own solution, it’s worth looking into how Tyler handled it. Very cool.

Surui said:

The eye thing is similar to windows 8. It’s interesting that in windows 8 the default is to hide, and only when you hold you see the password. It’s like a quick look.

Permalink to Surui’s comment

Replies to Surui

Mark Mitchell replied:

Yep, first thing I thought of as well. Internet Explorer 10 also has this functionality built-in for all password fields. Hopefully the other browsers will notice and follow suit.

I also like how they implemented it to mask by default, but then with click and holding on the eye you can quickly check for any typos before submitting. Perfect for touch enabled devices.

LukeW said:

The eye is for localization. Hide/unhide text string can run long when translated.

Permalink to LukeW’s comment

Replies to LukeW

Tyler Sticka (Article Author ) replied:

Exactly!

The winking eye is just one possible style. Text is inserted into the toggle element, which you can style as you like. You can also customize the text in the options. So if anyone’s adamant about using “verbergen” instead of “hide” for their German-language app, they have the option of doing so.

Benny said:

I was just asking the developers to bring hide/show pwd features in the WP logins and found http://wordpress.org/plugins/easy-to-use/ . But your work can be carried to any custom apps too. Thanks for the nice work and share.

Permalink to Benny’s comment

Replies to Benny

Tyler Sticka (Article Author ) replied:

Thanks! Something that WordPress plugin doesn’t do is offer an inner toggle control that maintains input focus on tap. That’s the biggest thing I wanted this plugin to be able to do.

Permalink to Tyler Sticka’s reply
Replies to Tyler Sticka
Jason Grigsby (Cloud Four Team Member) replied:

Translating Tyler’s comment for those who haven’t dug into this in great detail, here is the problem.

Most of the show/hide password solutions I’ve seen incorporate a checkbox like the third example that Tyler’s plugin supports:
http://cloudfour.github.io/hideShowPassword/

If you open that example in Mobile Safari, start typing a password. Now toggle the checkbox. What happens?

You lose the keyboard. You have to tap back into the input to begin typing again.

Contrast that to the behavior of the top two examples with the toggle inside the input element. You can hide and show passwords to your heart’s content without the keyboard going away and without you losing your place.

The reason the keyboard goes away is because when you tap on a different element, the focus moves from the input (which triggers the appearance of the keyboard) to the new element which hides the keyboard. Maintaining focus on the input while also triggering behavior and showing a button was the real challenge.

I’ve not seen any other open solution that does this in the browser.

Dominik said:

Great plugin, but…

Just to let you know: I don’t like the color your “clicked” links get. As soon as you click any link it looks almost as if they are no links at all (actually your “unclicked” links are hard to see, too). Better go with some standards and – at least – give them an underline or make their color stand out a little more.

David Stenbeck said:

The Hide show password is clever indeed. I think it is a good addition, but in earlier discussions regarding this subject I believe that defaulting to hidden might be of interest as to not alarm users.

Also with the eye I must say that I consider it backwards. An open eye to me is an open eye. thus the open eye state would indicate that a password is visible. The closed eye would indicate that it is hidden.

Permalink to David Stenbeck’s comment

Replies to David Stenbeck

Tyler Sticka (Article Author ) replied:

If you instantiate the plugin but don’t specify whether or not to start it with a shown or hidden value, it will fall back to the “type” attribute of the input. If “password,” the input will remain hidden. If “text,” the input will remain shown.

I agree that the icon states could be interpreted as the current visibility state and not as the tap action. I decided to mimic the pattern adopted by the LinkedIn app and IE10/Win8 (open eye when hidden, closed eye when shown). I figured they probably did their homework.

If you view the demo source, you can see it’s just a CSS change to switch them if you so choose. Go wild!

Gerben Jacobs said:

The only reason I can think of to mask your password is if someone’s watching along. Presentations perhaps.

So then why is “visible” the default option? What if someone starts typing their password without thinking it’s vissible. You only need “corr” to social engineer that password into “correct horse battery staple”.

I’d suggest auto-hide and have the Hide/Show text available all the time, i.e. not just on :focus.

Clinton Gallagher @virtualCableTV said:

Good idea but IMO the default is bass ackwards.

I’m developing a password manager and use “peek” the exact same way but I chose to leave the initial entry masked. I’ve been known to have to get up to _____ and leave the display unmanned anf forgetting to disable peeking is all too easy if my bladder tells me its time to get up or else (lol) and I contend many of us do so too.

What I need to learn –now– is how a person can get a user name and password from a password manager running on a mobile phone and then use the user name and password with a mobile app that requires authentication.

Remembering the data doesn’t work and I don’t thinki we have a clipboard on phones so how is this getting done?

I’m all ears for opinions and practices on that context…