Prevent password caching

In a typical user edit page, I have a username, password and common detail fields.  However, whenever I submit the page, the common browsers ask if I want to save the password.  If the page is then reloaded (particularly in Firefox), the username and password fields repopulate with the stored value.  This could cause problems, with usernames or passwords being changed accidently.

Is there a way to prevent this check?  Through a meta tag, or something?  I'd rather not try to form unique field names every time...

LVL 16
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Maybe try the combination of both of these:


Response.Expires = -1000
Otherwise it is in the hands of the user:

You can also add this in your form:


<INPUT TYPE = "password" NAME = "txtPassword" AUTOCOMPLETE = "off">
jimbobmcgeeAuthor Commented:
Neither seem to make a difference.

The particular problem is with FireFox; if FireFox smells a password field, when you click submit, it asks if you want to save the password.  If the user does this only once, the next time you access that page, the username and password fields are automatically populated with the password.  
If this happens on an 'Account Details' page and the user then hits 'save', the user is saved with the wrong, prepopulated username and password.

Much hilarity ensues, as users complain that they can't login because their usernames and/or passwords have been changed by someone who just wanted to update a telephone number...

Any other ideas...

Starting with Angular 5

Learn the essential features and functions of the popular JavaScript framework for building mobile, desktop and web applications.

What happens if you do this:

<input type="password" value=" ">

Just an idea, since you would be putting a space in by defualt?
or just <...... value=""> with no space?
Well the concept that anyone can edit a single form which includes telephone number and password of a user is wrong. You should have seperate forms for that, one in which the user can update his own password, and another in which other data can be changed.

Furthermore, it seems strange that you apparently do not check if the person who is logged in is the same person who updates the form.
Incidentally autocomplete=off support is being hotly debated by the firefox developers.  

Pros n cons
-  Websites should not dictate how a user works with their browser
-  Storing of passwords is a security concern to financial institutions

Ultimately sybe brings up the best point here, most sites (and applications/Operating Systems for that matter) recognize password mamagement as being
different from profile/account management
Hey, check the case in your HTML, tags and attributes should be lowercase.

If this is XHTML, your browser is gonna start ignoring all sorts of stuff on you.
jimbobmcgeeAuthor Commented:
>> Well the concept that anyone can edit a single form which includes telephone number and password of a user is wrong.

Agreed, but not something I can change -- it's in the FS: "User details page, where account, password and personal details can be changed by an administrator".  Gotta love business people and their little rules.  Still, separating the account and personal details isn't going to fix the issue; it's still going to update.

I'm going to have to add a GUID to my field names, aren't I...

Maybe not, why not change just the password fields in your edit form,
the problem maybe your login page uses the same field names as the edit page.

Since the user accepted the "save password" and corporate policy did not disable
that feature, I must assume that your user wants to be able to bypass logins from
his/her desktop.

Changing the field names in anyway prevents association with the saved password
data, and Mozilla/Firefox use a different heuristic if more than those two fields
are present, so the "Save Password" prompt should not come up on further edits.

Oh, is the change password portion of the page in its own form?  If so, you might want to incorporate that into the same main form but with a different submit button

A GUID is fairly overkill I think...

 (Tested solution in Moz 1.7.8, 1.7.12, Firefox

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Another comment is that autocomplete for passwords is honored only for encrypted forms, so you might want to consider moving a portion of this into SSL.

Cheers again,
ThinkPaperIT ConsultantCommented:
Is there anyway to set the passwords field blank by default? I'm wondering if this overrrides your autocomplete problem. Also, what does your form look like?

I'd assume it has a confirmation part so they'd have to type in their old and retype the new pws in to confirm.

old password:
new password:
new password: (confirm)


user clicks submit

If oldpw checks out and newpw = newpw2 AND newpw <> "" And newpw2 <> "" Then
   Update user info AND password
  Update user info NOT password
End If

Passwords shouldn't be overwritten by default.
>>Maybe not, why not change just the password fields in your edit form,
>>the problem maybe your login page uses the same field names as the edit page.

If this is the case you may also look at generating a random field name each time the page loads, then the likelyhood of the password name field may being the same twice is significantly reduced?
Thats what the poster suggested, and no, don't use random ever unless
you understand it.    The GUID is a better approach, but its still overkill
for this scenario.

One last try:

With further research I discovered the autocomplete=off works:

For IE in both the <form> and individual <input> tags.

For Firefox only in the <form> tag

You may want to try to test this ...
jimbobmcgeeAuthor Commented:
I couldn't get autocomplete to function consistently enough so I went with a GUID in the end; it was clean enough to code and a little more 'universal'.  

Thanks to all.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.