Author Topic: Encrypt text field autopopulate in storage, add hash populate to Adv. AutoPopula  (Read 10138 times)

julian

  • Guest
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?

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3352
    • http://passwordmaker.org/
Hi Julian,

It is a valid request, but our typical response to more encryption has been to use TrueCrypt or some other AES-256 3rd-party encryption tool for encrypting the passwordmaker settings file. Ultimately, such a tool will provide you more security and an additional layer above and beyond PasswordMaker (that's a good thing). What do you think?

Eric

julian

  • Guest
I don't know that utility.

Would I still be able to synchronize the file using the upload / download feature of passwordmaker?

As another thought, are there any other file synchronizers that may do this automatcally?

julian

  • Guest

Also, wouldn't I have to keep track of an additional password (instead of just the master?)

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3352
    • http://passwordmaker.org/
TrueCrypt: http://www.truecrypt.org/


Also, wouldn't I have to keep track of an additional password (instead of just the master?)
Yes, but you can make the TrueCrypt password the same as your PasswordMaker RDF password.

Yes, you'll still be able to synchronize.

Offline securesurfing

  • Normal Members
  • *
  • Posts: 2
our typical response to more encryption has been to use TrueCrypt or some other AES-256 3rd-party encryption tool for encrypting the passwordmaker settings file.

Eric

I don't quite understand how this would work. I use TrueCrypt to encrypt a USB drive. Firefox is run from the encrypted partition, once it has been opened by entering the appropriate TrueCrypt password.

I can't see how you would sensibly encrypt a single file like passwordmaker.rdf before running FF without it being a very manual task. Unless I've completely missed it, TrueCrypt does not have right-click context functionality so the user must first manually run TrueCrypt, then in the Select File dialogue navigate through the Docs & Settings to the FF profile directory and then Mount that file to a drive letter.

FF and PasswordMaker would not know how to find the rdf file on the separate logical drive, so you're still hooped. PasswordMaker does not appear to have the ability to set a different location for its config/settings file(s).

Is the suggestion to always run Firefox from an encrypted partition/TrueCrypt file?

Since Firefox always goes looking for its config files in the D&S....obscure-profile-directory, isn't the suggestion equivalent to recommending encrypting the entire System drive or in the alternative to use Portable Firefox?

I joined the forum because, as I was working with PasswordMaker (a fantastic piece of work that is a great benefit to the web surfing community!) I discovered what I consider to be a bit of a weakness that has to do with Prefixes.

There are numerous instances where a user does not get to set their own password. I know of at least two banks that provide hardened passwords to their customers for online banking. The password is created within the banks' own online facility. The work-around I am using to enable secure surfing with good ease is to copy the password given to me into the Prefix field in the PasswordMaker account and to set the Password length to the length of that Preifx-now-password.

This has worked fine to incorporate many passwords that predated the installation of PasswordMaker.

The downside is that the Prefix field is stored in clear text in the rdf file. Since the pwd length is also stored in  clear text, anyone with access to the FF profile directory will quickly deduce the prefix is in fact the password.

Given this issue, I joined the forum to suggest encrypting either the entire rdf file or at least the prefix value.  I did a search of this forum to avoid submitting a request that has already been addressed and sure enough I found the above quoted answer.

I guess I'm asking if there is any chance that prefix value encryption can happen or alternatively allow the explicit setting of the PasswordMaker Settings directory so it could point to an encrypted logical drive.

Great work regardless!

Offline Eric H. Jung

  • grimholtz
  • Administrator
  • *****
  • Posts: 3352
    • http://passwordmaker.org/
If you use advanced auto-populate to store the password provided to you by those banks, the password is encrypted in the passwordmaker.rdf file. There's no need to use the prefix in the way you described.

As for TrueCrypt, if you're unable to encrypt a file or directory with TrueCrypt (only volumes/partitions) then I'd switch to another solution if you're unwilling to encrypt your volume. For instance, Windows has had the ability to encrypt individual files and folders since I think Windows 2000. Ubuntu automatically encrypts everything in your home directory and you can get it to encrypt any arbitrary directory you like.

You are right that there is no way to point PasswordMaker to a user-defined path right now.

Offline tanstaafl

  • Administrator
  • *****
  • Posts: 1363
You are right that there is no way to point PasswordMaker to a user-defined path right now.

There is a Feature Request for this... and I personally would find it very useful...

PasswordMaker Forums


 

anything