Simulate password input box

During a log-in process there are times when I want autocomplete to work and times that I don’t (for security reasons). But even with autocomplete turned off, Firefox obligingly fills in the password once I supply the name.

To get around this (and fool Firefox), I’d like to simulate the HTML <input type=“password”> element with a javascript snippet that echose asterisks to an ordinary <input type=“text”> field. Does anyone have one of these floating aroun

Instead of trying to fake your way around, learn to control your web browser instead.

With Firefox, go to Tools -> Options -> Security -> Saved Passwords
and remove the passwords that you don’t want your web browser to remember.

Hi jrisken,

I turned off the autocomplete and it seems to work fine in firefox(my version 3.6). Please see the code below, here the for the first input field I have turned off the autcomplete and the second field I have not and it seems to be working


<form action=“form_action.asp” method=“get”>
First name: <input type=“text” name=“fname” autocomplete=“off”/><br />
Last name: <input type=“text” name=“lname” /><br />
<input type=“submit” value=“Submit” />


Hi johnny, thanks for responding. The trouble that the Original Poster is having is not related to autocomplete, which is why turning it off doesn’t solve the problem.
Instead, the web browser is filling in the password that it has previously been told to remember.

The solution is to remove that password from the list of passwords that the web browser remembers.

Also, from Tools -> Options -> Security you can tell Firefox whether it should remember passwords at all.

Hi pmw57
Thats makes sense

It’s not my browser I’m worried about. Presumably, if I can write JS I can configure the browser on my computer. It’s the browsers that the users of my application are using - whose configuration I obviously have no control over and which may sometimes be in a public place.

Firefox does indeed supply the saved password if the non-password box(es) are filled in correctly. I believe that their internal algorithm for supplying that fill-in depends on the html input type equaling ‘password’. So I want to be able to simulate the password functionality without using that ‘password’ type.

Now, you might chose to argue that what I’m trying to do makes no sense; but in the usage context for my application it makes perfect sense. Which is why I asked if anybody had anything that could do the emulation.

What on earth are you creating that would demand that I am forced to enter the password, instead of allowing me to have it remembered, if I so choose to, by my web browser?

…for my application the feature makes perfect sense. I take it you’re not aware of a useful snippet of code.

Not readily to hand. It’s a technique that’s is used when taking control of individual keystrokes entered into an input field.

The following resource on detecting keystrokes should be of further help for you.

I already have a sudoku-helper app that filters for numeric keys and enables directional arrows. It’s just that I estimate that writing and debugging the password module would probably take about three hours, and I’m not into reinventing the wheel when I can avoid it.

I didn’t answer your implied question earlier about why I would want to make your password life harder:

My application is not one in which really important or unique resources are at stake. If it were, I would turn off all autocomplete and run under https. But the resources do have some value and my users are all volunteers who sometimes work at public wifi.

When they work at home, I want them to be able to let the browser do the remembering. When they work in public, I would hope they’d be smart enough not to have the browser store their info; but if they’re not that smart, and they leave the app up and someone else comes along after they time out and are forced to relog, I don’t want their stored info to let the intruder relog just by bringing up the form.

What I want to do is just a small, incremental level of security against foolishness and opportunism.

Well you could use the same or similar keystroke capturing event on the fake password field, and replace all the characters in the field with asterisks.

You shouldn’t have to do anything special when tab or enter is pressed. Just allow them to carry on through and the form will handle those as per usual.

If the field is displaying the password as asterisks then anyone can easily run a simple JavaScript to extract it as plain text. Displaying it as asterisks just prevents someone seeing the password by looking over your shoulder when you paste it into the field. If you type it in then they can see it as you type by watching the keyboard. If you walk away with the field filled in and displaying asterisks then they just convert back to plain text and then they know your password.

Well, slightly more complicated. My PHP code generator needs to create a text field and a hidden field. In JS I need to intercept all keypresses to the text field and store them in the hidden field, replacing the character headed for the text field with an asterisk.

And I have to handle the backspace, which is trivial, and the use of cursor keys to land in the middle of the growing text string, which is non-trivial.

As long as the hidden field, which contains the password, is sent by submit(), I’m home almost free - except for some server-side code that populates the text field with asterisks and the hidden field with the real thing in case there’s an error in the form and resubmission is required.

Response to Chapman. You’re correct. And if I had high-value material in the application, I’d stay with https and not allow any caching of passwords at all. In this situation I’m really worried more about casual opportunism than I am about deliberate intrusion.

Oh. And I’d also do IP restriction and personal challenges.