? Security bug in documentation

[Julian]

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.

[julian]

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?

[Eric H. Jung]

Why wouldn't you use 3rd-party encryption of the passwordmaker.rdf file? TrueCrypt, for instance?

[Miquel 'Fire' Burns]

Actually, I don't use PasswordMaker for those, but I created a system to create a lie that I can reproduce later on. Actually, I don't believe I ever once told the truth to any of those questions.

The image thing is another thing that doesn't really protect you actually. All a hacker would need to do to by pass that is to have their host act as a proxy and transfer the information raw, and read the data you post to their server before passing to the server they're selling passwords for (PasswordMaker would send the wrong password if you use it correctly however, but may get those answers as a result... Hmm...)