Skip to main content
replaced http://security.stackexchange.com/ with https://security.stackexchange.com/
Source Link

There are different features at play here. Browsers offer to autocomplete text fields with previously entered values, which requires storing a history of the values previously entered in the same field. This history is stored in clear text and without any user feedback. A password field should never be subject to such history storage and autocompletion.

Browsers also have a distinct feature specifically targeted towards passwords. Passwords (that the web page declares as such) are only stored if the user explicitly answers “yes” to a prompt — most browsers ask some variation on “Do you want to save passwords? Yes / No / Never for this site”. Furthermore, the user can put a master password on password storage, which protects the passwords while the user is not using the computer.

In most cases, you should declare passwords as such, and allow them to be saved in the browser. This puts the responsibility of password security on the user, and as Tom Leek explains wellas Tom Leek explains well, this is usually the right thing to do. If you don't do it, users are likely to write the password in a text file. If users use a shared or trojaned computer, they've lost anyway. If the user would consent to password storage, there's nothing to be gained by denying him that feature.

There are different features at play here. Browsers offer to autocomplete text fields with previously entered values, which requires storing a history of the values previously entered in the same field. This history is stored in clear text and without any user feedback. A password field should never be subject to such history storage and autocompletion.

Browsers also have a distinct feature specifically targeted towards passwords. Passwords (that the web page declares as such) are only stored if the user explicitly answers “yes” to a prompt — most browsers ask some variation on “Do you want to save passwords? Yes / No / Never for this site”. Furthermore, the user can put a master password on password storage, which protects the passwords while the user is not using the computer.

In most cases, you should declare passwords as such, and allow them to be saved in the browser. This puts the responsibility of password security on the user, and as Tom Leek explains well, this is usually the right thing to do. If you don't do it, users are likely to write the password in a text file. If users use a shared or trojaned computer, they've lost anyway. If the user would consent to password storage, there's nothing to be gained by denying him that feature.

There are different features at play here. Browsers offer to autocomplete text fields with previously entered values, which requires storing a history of the values previously entered in the same field. This history is stored in clear text and without any user feedback. A password field should never be subject to such history storage and autocompletion.

Browsers also have a distinct feature specifically targeted towards passwords. Passwords (that the web page declares as such) are only stored if the user explicitly answers “yes” to a prompt — most browsers ask some variation on “Do you want to save passwords? Yes / No / Never for this site”. Furthermore, the user can put a master password on password storage, which protects the passwords while the user is not using the computer.

In most cases, you should declare passwords as such, and allow them to be saved in the browser. This puts the responsibility of password security on the user, and as Tom Leek explains well, this is usually the right thing to do. If you don't do it, users are likely to write the password in a text file. If users use a shared or trojaned computer, they've lost anyway. If the user would consent to password storage, there's nothing to be gained by denying him that feature.

Source Link

There are different features at play here. Browsers offer to autocomplete text fields with previously entered values, which requires storing a history of the values previously entered in the same field. This history is stored in clear text and without any user feedback. A password field should never be subject to such history storage and autocompletion.

Browsers also have a distinct feature specifically targeted towards passwords. Passwords (that the web page declares as such) are only stored if the user explicitly answers “yes” to a prompt — most browsers ask some variation on “Do you want to save passwords? Yes / No / Never for this site”. Furthermore, the user can put a master password on password storage, which protects the passwords while the user is not using the computer.

In most cases, you should declare passwords as such, and allow them to be saved in the browser. This puts the responsibility of password security on the user, and as Tom Leek explains well, this is usually the right thing to do. If you don't do it, users are likely to write the password in a text file. If users use a shared or trojaned computer, they've lost anyway. If the user would consent to password storage, there's nothing to be gained by denying him that feature.