don't auto-populate username if MPW not entered correctly

[Eric H. Jung]

Well, I'm not sure I even understand it anymore. What's all this about master usernames, profiles, and hiding the advanced dialog?

As I understand it, you simply want the ability to protect passwordmaker.rdf from prying eyes--whether it be by using PasswordMaker when they're not supposed to, or by opening the file in notepad.

If that's the case, I have to agree with a variation on what miquelfire is saying. You should be prompted for a password with which to encrypt the passwordmaker.rdf file. When starting PasswordMaker (assuming you've opted for this option), you'll be prompted for that password--which may or may not be your MPW (that's up to you). If you enter it incorrectly, a new file is created with defaults -- not overwriting passwordmaker.rdf, but perhaps named something like passwordmaker2.rdf. If, however, you enter the password correctly, then the original RDF is used.

The only problem I see with this is that the RDF must remain encrypted on disk. This will have an impact on performance.

[tanstaafl]

As I understand it, you simply want the ability to protect passwordmaker.rdf from prying eyes--whether it be by using PasswordMaker when they're not supposed to, or by opening the file in notepad.

If that's the case, I have to agree with a variation on what miquelfire is saying. You should be prompted for a password with which to encrypt the passwordmaker.rdf file. When starting PasswordMaker (assuming you've opted for this option), you'll be prompted for that password--which may or may not be your MPW (that's up to you). If you enter it incorrectly, a new file is created with defaults -- not overwriting passwordmaker.rdf, but perhaps named something like passwordmaker2.rdf. If, however, you enter the password correctly, then the original RDF is used.

Hence my question re: profiles...

If the above occurs, you now have two RDF files - which, essentially, is two PM 'profiles' (although the profile is merely another RDF file). So, if the above happens, how do you switch back to your original?

Maybe it would be better to simply not open the file without the PW (for now).

One advantage to the concept of PM 'Profiles' is this dovetails with the issue of Synchronizing settings - because this will obviously entail working with multiple RDF files.

The only problem I see with this is that the RDF must remain encrypted on disk. This will have an impact on performance.

How badly? I like the idea of having my RDF file protected, but as long as my passwords themselves are not in danger of being compromised, I don't think it's *that* important of an issue.

Hmmm....

[Romeo]

You should be prompted for a password with which to encrypt the passwordmaker.rdf file. When starting PasswordMaker (assuming you've opted for this option), you'll be prompted for that password--which may or may not be your MPW (that's up to you). If you enter it incorrectly, a new file is created with defaults -- not overwriting passwordmaker.rdf, but perhaps named something like passwordmaker2.rdf. If, however, you enter the password correctly, then the original RDF is used.

Yes Eric, that is more or less what I am trying to say.

[Eric H. Jung]

If the above occurs, you now have two RDF files - which, essentially, is two PM 'profiles' (although the profile is merely another RDF file). So, if the above happens, how do you switch back to your original?

OK, now I understand what you meant by a profile. One way of switching back to the other profile is by using File->Import Settings (you'd once again be prompted for the password for that file).

The only problem I see with this is that the RDF must remain encrypted on disk. This will have an impact on performance.

How badly? I like the idea of having my RDF file protected, but as long as my passwords themselves are not in danger of being compromised, I don't think it's *that* important of an issue.

Well, I re-thought this and most everything that's used frequently is cached in memory. So the performance hit wouldn't be bad at all. It's the coding effort for something like this that would be huge.

I think we should just stick with the original idea of hiding the accounts tab if the MPW isn't entered correctly (and the user has chosen this global setting).... no encryption of passwordmaker.rdf, at least not yet.

[Romeo]

I think we should just stick with the original idea of hiding the accounts tab if the MPW isn't entered correctly (and the user has chosen this global setting).... no encryption of passwordmaker.rdf, at least not yet.

Yes Eric, I do not even know how we got to this point.  I was looking thru this thread earlier today and was shocked at how long it has gotten.

As long as it is a choice to do it, or not, let's just hide the account tree.  The user could always use the operating system functions to encrypt the rdf file.

or as my daughter would say:  whatever ?

[tanstaafl]

Agreed...

[LkonKbd]

I hope this is the way to vote for the one or 5 you like.

I agree with this as I have had this very problem many times, as I use the single MPW entry.  This one would be GREAT for those of us that have the un-educated fingers and do not know how to dpwell, (sp), spell.  I would take them back to school, but; that is about 30 miles from here and over 45 years ago.

This is Numbre 3,

[esallc]

I vote for encrypting the output from Advanced Auto-Populate fields based on the master password (in addition to encrypting the .rdf file during import/export).

[tanstaafl]

Combined with New 'MPW Hash Mis-Match' dialog