PLEASE READ FOLLOWING TWO POSTS WITH SUGGESTIONS
The Passwordmaker web site FAQ contains the following suggestion for people who want to keep and store their own passwords (not those chosen by the hash algorithm):
http://passwordmaker.org/Faq.html#If_I_don.27t_want_to_change_all_of_my_passwords.2C_is_PasswordMaker_still_a_good_choice.3F>
> If I don't want to change all of my passwords, is PasswordMaker still a good choice?
>
> Yes. PasswordMaker provides a secure method for encrypted storage of a specific,
> user-provided password for a custom Account. This way you can take advantage
> of PasswordMaker's other features (such as form completion) while still choosing your
> own passwords.
>
> To set up a URL/site in this manner, simply go to the login page for the Account that
> you want to save the password for, create a new (or open the existing) Account for
> this URL/site, change to Advanced Options (if you are not already there), click
> the Advanced Auto-Populate tab, click inside the password field on the login page,
> click inside the Field Value field, enter your current password, then click the Add>
> button (just above the list-box for fields), and last but not least, if desired, check
> Auto-populate username and password fields for sites that contain this URL.
>
Correct me if I am wrong, but the statement "PasswordMaker provides a secure method for encrypted storage of a specific, user-provided password" is incorrect so far as it is implied. Using Advanced auto populate in this fashion, the user-provided password is NOT encrypted in storage. Anyone opening the web browser and looking into the PasswordMaker setting can read the user entry in the field value and retrieve the password so entered, even when the master password has not been entered or kept in storage. Am I correct?
Can anyone else verify this?
Would be nice if you could have additional hashed password to populate using this feature though.
Logged
julian
Guest
Re: ? Security bug in documentation
« Reply #1 on: Today at 04:43:48 AM »
Reply with quoteQuote
Oh crud. It works but the answer is stored only in encrypted form, only if the "field type" is "password."
So it does work, but not if the "field" type is "text."
And if you choose a field that is of "password" type and try to populate a field on a web page with an encrypted piece of information that is not a designated "password" field but a "text" field then it won't populate that text field at all.
This is a design limitation. Nowadays, there are many web sites that will try to get you to enter additional information such as "mother's maiden" name and so forth as backup for password retrieval or as "additional security measures." In reality though, this only decreases the security of your site, as much of this information can be retrieved and can be used to gain unauthorized access (e.g. hacking of Gov. Palin's email account see
http://www.fool.com/investing/general/2008/09/19/hacker-catches-yahoo-off-guard.aspx).
I am currently running in to problems with my bank which is mandating these asinine questions be answered at login from time to time, and I'll be damned if I'm going to use that information to "protect" (acutally "unprotect") my bank accounts. Totally retarded, I know, but other than switching banks, which may be a good idea, they leave me no choice.
It would be useful to use passwordmaker to populate these fields with phoney information unique to each web site (actually, secure passwords instead of English answers which may be known or retrievable by others). But because PasswordMaker does not:
(a) Encrypt text field information stored in Advanced Auto-populate.
(b) Allow password field entries stored in Advanced Auto-populate to be used to populate text fields on web pages...
... this is currently not possible.
Why is it necessary to store field population information for passwords so entered but NOT to store text field answers as encrypted? Are there security benefits to not encrypting text field answers stored in the passwordmaker user data file?
It would be even better to have a feature in autopopulate where additional fields other than the password field can be populated with hashes, but that may be too complicated.
Also, beware, users reading the above FAQ may be fooled into believing text fields stored in Advanced Auto-populate are stored in encrypted / safe form when they are not.
Is this a possible feature request then?
