[Last Call] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1194
  • Last Modified:

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...

J.
0
jimbobmcgee
Asked:
jimbobmcgee
  • 6
  • 5
  • 3
  • +2
2 Solutions
 
rockymageeCommented:
Maybe try the combination of both of these:

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">

<%
 ' NO CACHE
Response.Expires = -1000
%>
0
 
rockymageeCommented:
Otherwise it is in the hands of the user:

http://itinfo.mit.edu/article.php?id=6707

You can also add this in your form:

<FORM AUTOCOMPLETE = "off">

<INPUT TYPE = "password" NAME = "txtPassword" AUTOCOMPLETE = "off">
0
 
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...

J.
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
rockymageeCommented:
What happens if you do this:

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

Just an idea, since you would be putting a space in by defualt?
0
 
rockymageeCommented:
or just <...... value=""> with no space?
0
 
sybeCommented:
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.
0
 
wnrossCommented:
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
0
 
wnrossCommented:
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.
0
 
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...

J.
0
 
wnrossCommented:
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...

Cheers,
-Bill
 (Tested solution in Moz 1.7.8, 1.7.12, Firefox 1.5.0.2)
0
 
wnrossCommented:
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,
-Bill
0
 
ThinkPaperCommented:
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)

So:

user clicks submit

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

Passwords shouldn't be overwritten by default.
0
 
rockymageeCommented:
>>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?
0
 
wnrossCommented:
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.

Cheers,
-Bill
0
 
rockymageeCommented:
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 ...
0
 
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.

J.
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 6
  • 5
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now