Closed Bug 506638 Opened 15 years ago Closed 6 years ago

migrated SM2 from SM1 is asking for master password after first start even when no master password was set in SM1.1.x

Categories

(SeaMonkey :: Passwords & Permissions, defect)

Product:
SeaMonkey
Component:
Passwords & Permissions
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INACTIVE

People

(Reporter: prof, Unassigned)

References

(
URL
)

Details

(Whiteboard: [gs][3.6.x])

Attachments

(1 file)

test program to analyze key3.db initialization state
12.65 KB, application/zip
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9.1.1pre) Gecko/20090717 SeaMonkey/2.0b1

When migrating from Seamonkey 1.1.17 to SM2.0b1 (including the import of data from SM1), SM2 asks for a master password right on the first start (probably due to trying to fetch mail already) although there has no master password been used in the existing SM1-installation.

The master password has to be dismissed twice (guess that's related to other already known bugs concerning multiple MP-prompts, rather than this one) in order to get to the next window (set standard application).
http://img193.imageshack.us/img193/4008/smmapw1q.png
http://img193.imageshack.us/img193/1361/smmapw2s.png

According to newsgroup posts the problem seems to exist for others on WinXP, too.

Reproducible: Didn't try

Steps to Reproduce:
1. Install SM2.0b1 on a machine with SM1.1.17 and import all data
2. Start SM2.0b1
3.
Actual Results:  
Master Password prompt comes up.
http://img193.imageshack.us/img193/4008/smmapw1q.png


Expected Results:  
No master password prompt
http://img193.imageshack.us/img193/1361/smmapw2s.png

fault can be fixed by deleting the file key3.db
No MP-prompt on start and all paswords are accessible then.
Looks like we heard this multiple times with 2.0b1 installations. Standard8, any idea what's up? Neil, you looked into crashes due to migration not knowing correctly about the switch to the new password manager, could this be connected?
Component: General → Passwords & Permissions
QA Contact: general → privacy
Wallet didn't encrypt passwords by default, so you weren't asked for a master password unless you performed certificate operations. Login manager requires encryption, unfortunately, so you need to know your master password.

Note that Login Manager encrypts "as soon as possible", i.e. the first time you enter your master password, which is how resetting the master password (possibly there's a safer way than deleting key3.db) seemed to work.
Neil, it's true that it requires encryption, but by default it uses an empty master password, for which we usually don't prompt, so I wonder why a prompt comes up for those people (and it's apparently not reproduceable for everyone, other people say they don't get it).
Confirm: I *can* reproduce on Win2KPro. I *cannot* reproduce on linux.

Environment: Win2KPro Service Pack 4 (running in VirtualBox).
SM 1.1.17 with one pop account set, no Master Password - only password for fetching mail from the pop account. 1.1.17 is installed to C:\seamonkey

Uninstalled previous SM 2.0b1 that I'd been using for testing - reinstalled & allowed 2.0b1 to install to the default C:\Program Files\SeaMonkey directory. Initialized 2.0b1, opened the mail window, checked to make sure that my 1.1.17 messages were imported etc., they were. Clicked 'Get Messages' and was prompted for a Master Password. 

The '.s' file from 1.1.17 is present in the 2.0b1 profile folder, and I am showing multiple 'places.sqlite.corrupt files in the folder. I've not yet deleted key3.db or anything else at this point, simply closed SM. Anything that I can check further to assist?
Run 1.1.17, then go to Edit - Preferences - Privacy & Security - Master Passwords - Change Password. Does it say Current Password: (not set) [but greyed out] or are you expected to type in your current password?
1.1.17 shows 'Current Password: (not set) [but
greyed out]'. I pulled the profile over to my host (linux) and using sqlite browser I see that there is an encrypted record in signons.sqlite for the pop password. Note: the Win2KPro setup is primarily only for testing, so no worries about breakage if you need me to delete/modify something.
Neil, thanks for the heads-up about this in dev-tech-crypto. 
Feel free to add me to the cc list of a bug that involves NSS questions.

I've just been discussing this with Bob Relyea, who's the real expert on 
behavior of NSS with respect to key DBs and their passwords.  I want to 
not further burden him with this unless/until we become pretty sure that 
there's an NSS bug here, and what it is or how to reproduce it without 
SM 2.0mumble.  It may be an NSS problem, or maybe not.  Let's try to 
figure that out first.

You wrote that "Some users [...] have been complaining that the resulting profile claims to have a master password."  User "NoOp" claims this is 
platform dependent, and for Win2k.  Are there other users who have reported 
similar problems on other platforms?  I think the first big question we must
resolve is: is this truly platform-dependent behavior?  and if so, "What 
are the platforms that are affected?"  Is it just windows?  just win2k?  

What exact version of nss is being used in the SM 2.0mumble installation 
that exhibits this problem?
I've just now managed to reproduce on WinXPPro SP3, so maybe it's a Windows issue. Sorry, I've no other environments (Mac etc) to test with: only Win2KPro, WinXPro, and linux (Ubuntu 8.04 & 9.04).

Can someone please change the 'Status' to 'New' rather than 'Unconfirmed'?
(In reply to comment #7)
> What exact version of nss is being used in the SM 2.0mumble installation 
> that exhibits this problem?

All SeaMonkey 2.0 versions are using the mozilla-1.9.1 tree, so the NSS version contained there is what applies here.
I'll leave the other things to Neil, as I don't really understand code details.
In the discussion thread about this, seen at 
http://groups.google.com/group/mozilla.support.seamonkey/tree/browse_frm/thread/ed423bec2145ac28/07a3ad010ea15bac?rnum=1&_done=%2Fgroup%2Fmozilla.support.seamonkey%2Fbrowse_frm%2Fthread%2Fed423bec2145ac28%2F7a3ad010ea15bac%3Fq%3D%26#doc_81ff428ca78b0133
Martin Feitag (who, if I'm not mistaken) is the reporter of this bug wrote:

> Luckily after deleting key3.db all passwords are remaining intact and
> are accessible afterwards. So SM doesn't seem to encrypt with the "new"
> (not-existing) master-pw, it just thinks there is one or so (I don't
> know about the technical details). So deleting that file is the only
> solution for now afaik until this is fixed. 

If that is true, it's a BIG clue about what's going on here.  So I'm going 
to ask NoOp if he can confirm that simply moving key3.db away (e.g. renaming
it XXXkey3.dbXXX) solves the problem while leaving the original saved 
passwords intact.  NoOp, please see if you can confirm that.
This comment is for the SeaMonkey developers who are responsible for the 
migration from "wallet" in SM1 to the new "password manager" in SM2.  
I don't even know if those persons are CCed on this bug.  I hope so.

Assuming that Martin Feitag's statement about deleting key3.db works for 
others who have this problem, then I'm pretty sure I understand the problem.

In the old wallet scheme, the user had a configuration choice about whether
his saved passwords were encrypted or not.  If they were encrypted, then the
user was required to have a master password.  If they were NOT encrypted,
then it didn't matter if the user had a master password or not, because 
the encryption that requires a master password simply was not used.  

So, it was possible for a user to have a file of saved passwords that was 
not encrypted, and also have a master password that he had never used, or
had only used once (to set it) and then forgot it.  Since his saved passwords
were not encrypted, he was never asked for his master password to access those
saved passwords.  

The new "password Manager" software (used in Firefox for some time now, and
now brand new to SeaMonkey) was designed to always encrypt and decrypt saved 
passwords.  If the user didn't have a master password, it would setup a 
key3.db file with an empty master password, and use that.  The user would 
never be prompted for a master password in that case.  

Now, here's what I think is happening.  I think there are SM1 users who had
setup master passwords, but never used them and had forgotten them, because
wallet never required them.  When the file of saved passwords is migrated, 
it is more-or-less just copied (I believe it is converted from a plain text
file of base64 encoded records to a sqlite3 DB of those same base64 encoded
records, but no other changes are made, AFAIK.)  So the user's file of 
passwords is copied, and his key3.db is copied, and under SM2, the new 
password manager sees that the key3.db has a master password and says 
"Oh, this user's saved passwords MUST be encrypted, because there is a 
master password", so it prompts for a master password.  Evidently, if it
cannot find a master password, (or a key3.db) it is able to fall back on
the old scheme of using unencrypted but base64 encoded saved passwords.
So, moving the key3.db out of the way causes password manager to not 
try to decrypt the master passwords, and hence not to prompt for the 
non-existent master password.  

Now, assuming that theory is correct and can be experimentally corroborated, 
the following migration strategy should work.  

During the migration, if you see that 
1) the user has saved passwords, and 
2) user's old SM 1.x profile did not encrypt the passwords, and 
3) the user has a non-empty master password in his ley3.db, 
then ask the user to enter his master password.  Give him a choice to 
either provide it, or to say "I don't have one, or have forgotten it".

If the user enters the correct master password, then encrypt all the entries
as you migrate them to the new saved passwords DB.  This would be essentially
the same procedure used before with Wallet when the user created a master 
password after having previously saved passwords while he had no master 
password.  

OTOH, if the user says "I don't have one or have forgotten it", then do NOT
copy his old key3.db, but create a new one (with an empty password, the 
default), and encrypt all the passwords with the new key3.db file.  

Either way, the result will be that in the SM2 profile, the user's passwords
will be encrypted, just as they are for TB2.  The only difference will be
whether the user's new key3.db file has a non-empty master password or an 
empty one (for which he is not prompted).
Using the same testing scenario as #4: In Win2KPro I uninstalled 2.0b1 (including deleting C:\Documents and Settings\gg\Application Data\Mozilla\SeaMonkey), then reinstalled. Opened 2.0b1, imported 1.1.17 profile:

1. Checked to see that all of my emails from 1.1.17 are there (they are), 
2. Checked the password manager to see if my email password is there (it is),
3. Closed SM without attempting to 'Get msgs',
4. Renamed key3.db (x-key3.db-x) & reopened SM 2.0b1,
5. Check password manager & of course my email password is now no longer there as a new key3db is created on startup,
6. Click 'Get msgs' and I am prompted to enter my email password (no master password prompt). Enter the password, tick to save, POP account goes out and fetches emails & password is stored in password manager. 
7. Close SM and check again - password is still in the password manager.

Now... on a whim; I close 2.0b1, go back and:

1. Rename the new key3.db (y-key3.db-y), 
2. Make a copy of the old x-key3.db-x and rename it key3.db,
3. Open SM 2.0b1 and check to see if my email password is there; it is of course as this is from the original migration,
4. Click 'Get msgs' and it goes out an fetches from the email server with *no* master password prompt.
5. Edit|Preferences|Privacy & Security|Master Passwords|Change Password|Current Password: (not set) [greyed out]

I can test on WinXP as well if you'd like.
Just to verify the key3.db's that I tested:

This is the original from the migration:
$ md5sum x-key3.db-x
84269b7cbfb3250159dcd7381e51288b  x-key3.db-x
This is the one that was created in the first step #5 above:
$ md5sum y-key3.db-y
07718444a44a0c8aea095c2794fcab57  y-key3.db-y
This is the one that I used on the second step #2 above:
$ md5sum key3.db
84269b7cbfb3250159dcd7381e51288b  key3.db
and you'll see that it matches the one from the original migration.

So it appears to me that the key3.db file is not the issue, as using a key3.db generated using the same salt seems to work (I can swap between x-key3.db-x and y-key3.-y).
Please disregard my comments #12 & #13 for the time being. I found that the test run by uninstalling 2.0b1 (including deleting C:\Documents and Settings\gg\Application
Data\Mozilla\SeaMonkey) are invalid. I repeated the above without deleting the key3.db file and upon reinstall 2.0b1 is no longer asking for master password. My _guess_ at this point is that perhaps an MS registry key has been set, so I am testing with: 1) reboot to see if that clears it, and if not then 2) clean all registry keys of SM and see if I can repeat.
Reboot changed nothing, clearing registry with CCleaner changed nothing: reinstall of 2.0b1 afterwords still results in no Master Password prompt now. Any suggestions on what I might be looking for (registry keys etc) to get it back to the original issue state? Note: I'm primarily a linux guy, but most of my customers are Windows users so I also have experience w/Windows/regedit etc., and don't mind digging through the registry keys.
Mozilla's password manager doesn't use registry entries, AFAIK, so I think 
digging through the registry would be a waste of time.  

One question I do not know is whether the SM 1.x and SM 2.x profile directories
(where the key3.db file lives) are the same directory or separate directories. 
Either way, I am sure that uninstalling and reinstalling SM 2.x does not 
discard the SM 2.x profile.  So, if you install 2.x and run it, creating a 
profile directory, then uninstall and reinstall SM 2.x, the contents of the 
profile directory after the uninstall/reinstall are the same as before.  
They are not recreated from the old profile again simply because you 
uninstalled and reinstalled SM 2.x.  So, I think that uninstalling and 
reinstalling SM 2.x does not test anything useful with respect to this issue.

If you are able to access the same stored passwords with two separate key3.db 
files, then this strongly suggests that your passwords are stored unencrypted.

I will try to devise some tests that may be more conclusive.
NoOp, it would simplify my diagnosis tremendously if you could empirically 
determine whether the SM 1.x and SM 2.x profile directories are the same
directory or different directories.  I've been using SM 2.x alpha for so 
long (well over a year, more like two) that I no longer have any SM 1.x 
profiles left with which to test.
As mentioned in #4:
<quote> 
Environment: Win2KPro Service Pack 4 (running in VirtualBox).
SM 1.1.17 with one pop account set, no Master Password - only password for
fetching mail from the pop account. 1.1.17 is installed to C:\seamonkey
 .
 .
 .
Uninstalled previous SM 2.0b1 that I'd been using for testing - reinstalled &
allowed 2.0b1 to install to the default C:\Program Files\SeaMonkey directory.
</quote>

Would you like me to test with both installed to C:\Program Files\SeaMonkey?
(In reply to comment #16)
> Mozilla's password manager doesn't use registry entries, AFAIK, so I think 
> digging through the registry would be a waste of time.  
> 
> One question I do not know is whether the SM 1.x and SM 2.x profile directories
> (where the key3.db file lives) are the same directory or separate directories. 

The key3.db files live in the profile directories. 

> Either way, I am sure that uninstalling and reinstalling SM 2.x does not 
> discard the SM 2.x profile.  

I've already mentioned that I deleted the 2.0b1 profile in the process:

<quote>
(including deleting C:\Documents and Settings\gg\Application Data\Mozilla\SeaMonkey)
</quote>

So, if you install 2.x and run it, creating a 
> profile directory, then uninstall and reinstall SM 2.x, the contents of the 
> profile directory after the uninstall/reinstall are the same as before.  
> They are not recreated from the old profile again simply because you 
> uninstalled and reinstalled SM 2.x.  So, I think that uninstalling and 
> reinstalling SM 2.x does not test anything useful with respect to this issue.

See above.

> 
> If you are able to access the same stored passwords with two separate key3.db 
> files, then this strongly suggests that your passwords are stored unencrypted.

Of course they are stored unencrypted - that is the purpose of this test: migrating a 1.1.17 with no master password set (meaning the passwords *were* stored unencrypted) to 2.0b1 and attempting to figure out why a new migration is asking for a Master Password.

 Bug 506638 -  migrated SM2 from SM1 is asking for master password after first start even when no master password was set in SM1.1.x  when no master password

> 
> I will try to devise some tests that may be more conclusive.
OK, on the Win2KPro (VirtualBox VM) machine I blew out everything SeaMonkey; uninstalled 2.0b1, 1.1.17, deleted all profiles (C:\Documents and Settings\gg\Application Data\Mozilla\), used CCleaner to clean all registry entries SeaMonkey/Mozilla related, rebooted, ran CCleaner again to be sure, and (all to the default 'C:\Program Files\SeaMonkey' directory:

1. Installed 1.1.17:
 - default profile I added a valid email POP3 email account
 - checked to ensure it is working & saved the email password
 - *No* Master Password set - *only* the email account password
2. Created an additional profile (tests) and created an nntp account to news.mozilla.org:
 - Subscribed to seamonkey support & dev & checked to ensure those work
3. Exited 1.1.17
4. Installed 2.0b1
5. 2.0b1 prompted me to import my existing profiles (both default and tests), selected 'default. 
 - profile was imported/migrated properly
 - emails from 1.1.17 are there
 - Master password is not present
 - Email password *is* present
 - Clicked 'Get msgs' and 2.0b1 went out and fetched my additional emails without issue.

So, in summary: everything seems to be working now & I've no clue why: 1) it didn't work the first time (#4) and 2) why it's working now.
I think NoOp's tests substantiate Comment #11 From Nelson Bolyard (:MisterSSL).

My SM1.x installation on that machine is pretty old (concerning the profile). If it is possible to have a Master-Password without using it as he says, there might be a chance that there is a Master-Password set in that installation/profile which I'm no longer aware of.

His solution sounds reasonable to me, too.

I guess this issue is not OS-dependent then. Maybe someone can confirm that (even on another OS) with Nelson Bolyard's hints on how to prepare such a scenario (setting MP without using it for encryption of passwords).
(In reply to comment #11)
[long theory details that I like to think expands on comment #2]

> Now, assuming that theory is correct and can be experimentally corroborated, 
> the following migration strategy should work.  
> 
> During the migration, if you see that 
> 1) the user has saved passwords, and 
> 2) user's old SM 1.x profile did not encrypt the passwords, and 
> 3) the user has a non-empty master password in his key3.db, 
> then ask the user to enter his master password.  Give him a choice to 
> either provide it, or to say "I don't have one, or have forgotten it".
The big problem with migration is that it happens before profile startup (either the source or target profile). Some services, such as preferences, allow us to read and write files in specific locations rather than always using the profile, and we use this to migrate specific preferences from 1.x to 2.x, but the best we can do for most services is to simply copy over the appropriate files. (For instance, this causes a bug whereby we cannot guarantee to read the location of the original profile's email since it is stored in a profile-relative location and we have no profile for it to be relative to.) So although we can determine whether the user has saved passwords (by testing for the existence of the signons file) and whether the user has encrypted passwords (by testing for the existence of the wallet.crypto preference) we cannot log in to the key3.db file unless PSM happens to have some API to access a key3.db outside of the profile.
(In reply to comment #17)
> NoOp, it would simplify my diagnosis tremendously if you could empirically 
> determine whether the SM 1.x and SM 2.x profile directories are the same
> directory or different directories.

If he uses default locations (and I'm pretty sure of that), they're always different locations, as xpfe and new toolkit use different semantics for creating profile directories.
Version: unspecified → Trunk
@Nelson: I still have my Mozilla folder from the initial test (#4) where the Master Password came up. I just put that back to C:\Documents and
Settings\gg\Application Data\Mozilla\ and sure enough, 2.0b1 now prompts for the Master Password. Put the one (Mozilla folder) from #20 back and no prompt. So I have files to compare against. If you can tell me what to look for I can compare the MP (Master Password) against the NMP (No Master Password) files.
In reply to Neil's comment 22:
> [...] we cannot log in to the key3.db file unless PSM happens to have 
> some API to access a key3.db outside of the profile.

IINM, you copy the key3.db to the new profile during the migration, yes?
So, can't you use it in the current/new profile?

@NoOp, 
Your file of saved web site passwords will be in your SM 1.1 profile directory, 
the same directory as key3.db.  It will be named either "signons.txt" if
it was initially created relatively recently, or it will be named NNNNNNNN.s
(where NNNNNNNN is a random 8 digit number) if it was created long ago.

Either way, it's a text file and you can look at it with notepad.  If the 
passwords in it are encrypted, then you will see lines that look something 
like these:

> http://developer.mozilla.org
> name
> MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECE+7F [...]
> *password
> MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECCfiD [...]
> .

Note that the encrypted lines are long, start with 'M', and have lots of 'A's.

If your file was not encrypted, but merely encoded, then you will see lines
like these:

> http://www.mail.com
> login
> ~Zm9vxyxyxyxyxyxyxyx==
> *password
> ~Zm9vxyxyxy
> .

The encoded lines are relatively short, and begin with '~'.  They are NOT 
encrypted and you should not paste them into a bug.  

I predict that you will find your saved passwords start with '~'. 
The remaining question is about your key3.db file, which SM 1.x thinks has 
no master password, but the behavior of SM 2.x suggests that it thinks that
you DO have a master password.  The possibilities seem to be:
a) it does have a master password
b) it does not have a master password
c) it is in some self-inconsistent state that for some operations may seem 
to have a master password, but for other operations may seem not to.  

I'm trying to think of a way to determine which of those applies to your 
key3.db without examining it myself.  I may be able to send you a 
Windows program that will examine it much as I would and report findings.
(In reply to comment #25)
> In reply to Neil's comment 22:
> > [...] we cannot log in to the key3.db file unless PSM happens to have 
> > some API to access a key3.db outside of the profile.
> IINM, you copy the key3.db to the new profile during the migration, yes?
> So, can't you use it in the current/new profile?
Although the profile exists on disk, it's not actually loaded in to memory. That doesn't happen until the restart at the end of the migration.

Historical note for those people interested: The old XPFE profile system started off in a "no profile" state, which sufficed to launch the profile manager. You could also unload and load alternate profiles at any time during the lifetime of the process. All DOM windows had to be closed but components were expected to listen to profile notifications if necessary. The new toolkit profile system starts off in a specific state, either "no profile" or "specified profile". This state is selected very early on in the lifetime of the process and cannot be changed. Profile selection is emulated by restarting the process.
Neil, 
I think you cannot solve this problem without using NSS during the migration 
to access the key3.db file and the old saved passwords file in the old profile.
...
> @NoOp, 
> Your file of saved web site passwords will be in your SM 1.1 profile directory, 
> the same directory as key3.db.  It will be named either "signons.txt" if
> it was initially created relatively recently, or it will be named NNNNNNNN.s
> (where NNNNNNNN is a random 8 digit number) if it was created long ago.
> 
> Either way, it's a text file and you can look at it with notepad.  If the 
> passwords in it are encrypted, then you will see lines that look something 
> like these:
> 
> > http://developer.mozilla.org
> > name
> > MEIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECE+7F [...]
> > *password
> > MDIEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECCfiD [...]
> > .
...
Both the MP and NMP passwords are as above (encrypted format) in the 2.0b1 profile. I've checked both the signons3.txt files as well as the signons.sqlite files.

Both the MP and NMP passwords are in the unencrypted format in the 1.1.17 profiles. Note: there is no 'signons.txt' in the 1.1.17 profiles, only the <randomnumber>.s files.

> 
> I predict that you will find your saved passwords start with '~'. 
> The remaining question is about your key3.db file, which SM 1.x thinks has 
> no master password, but the behavior of SM 2.x suggests that it thinks that
> you DO have a master password.  The possibilities seem to be:
> a) it does have a master password
> b) it does not have a master password
> c) it is in some self-inconsistent state that for some operations may seem 
> to have a master password, but for other operations may seem not to. 

The key3.db files are a bit harder to look at; I've checked in gvim (hex mode).
 
> 
> I'm trying to think of a way to determine which of those applies to your 
> key3.db without examining it myself.  I may be able to send you a 
> Windows program that will examine it much as I would and report findings.

Windows or linux program will do. Happy to help if I can.
NoOp, you wrote:
> Both the MP and NMP passwords are [...]
What do you mean by MP and NMP passwords?  

The NNNNNNNN.s files and signon.txt files are merely two different names for
the same exact type of file.  It contains web site passwords only and never
contains the "master password".  The encoded passwords occupy lines that 
may start with 'M' or '~'.  

Attached here is a zip file containing a single executable file.  
Unzip it into the directory where TB 2.0bN's thunderbird.exe is installed,
which is also where files such as nss3.dll and softokn3.dll are installed.
Run any anti-virus scans on it as you deem appropriate.

To run it using a "cmd" windows, 
1) make sure that thunderbird is not running.
2) cd to the directory where thunderbird.exe is installed, and 
3) run the command with a command line like this:
    dbpwstate -d "<path to TB2 profile>" 
e.g.
    dbpwstate -d "C:\documents and settings\myuserid\<and so on>"

This *may* or may not prompt you for a password.  Eventually it will output
one line which will be one of:

Slot "<name>" needs User initialization.  It has no password.

Slot "<name>" has a non-empty password.

Slot "<name>" has an empty password.

Or perhaps an error message such as:

dbpwstate: NSS_Init failed, could not open DBs

dbpwstate: No Internal Key Slot!

dbpwstate: Internal Key Slot has no name!

If you wish, you may also run it giving the path name of the TB 1.x profile.
Please let us know the results.
(In reply to comment #29)
> Created an attachment (id=392436) [details]
> test program to analyze key3.db initialization state
> 
> NoOp, you wrote:
> > Both the MP and NMP passwords are [...]
> What do you mean by MP and NMP passwords? 

Sorry, it was shorthand from my comment #24 so that I can keep track of which profile I am referring to:
"If you can tell me what to look for I can
compare the MP (Master Password) against the NMP (No Master Password) files."

As mentioned, I have the kept copies of the profiles for: 1) when I first tested and the migration caused 2.0b1 to prompt for a Master Password (MP), and 2) when I tested again by deleting all things SeaMonkey on the machine, reinstalling 1.1.17 and 2.0b1 and 2.0b1 that time did not prompt for a Master Password (NMP).
 
> 
> The NNNNNNNN.s files and signon.txt files are merely two different names for
> the same exact type of file.  

Understood. I was merely pointing out that my 1.1.17 profiles contain only NNNNNNNN.s files. There is no signon.txt file.

> It contains web site passwords only and never
> contains the "master password".  The encoded passwords occupy lines that 
> may start with 'M' or '~'.

Incorrect: "web site passwords only". The NNNNNNNN.s files (in both my MP and NMP profiles) contain the POP3 email account password that I stored when logged on to my email account. It will, of course, also contain website passwords if stored as well, but in these tests I've stored no web site passwords. The email account password issue is the jist of this bug;

"When migrating from Seamonkey 1.1.17 to SM2.0b1 (including the import of data
from SM1), SM2 asks for a master password right on the first start (probably
due to trying to fetch mail already) although there has no master password been
used in the existing SM1-installation."
 
Correct that it never contains the Master Password.

> 
> Attached here is a zip file containing a single executable file.  
> Unzip it into the directory where TB 2.0bN's thunderbird.exe is installed,
> which is also where files such as nss3.dll and softokn3.dll are installed.
> Run any anti-virus scans on it as you deem appropriate.

I am hoping that you mean "seamonkey.exe" rather than Thunderbird...
NoOp, did you do the requested test?  What were the results?
OK. Here are results. Note that I tested *both* the MP and the NMP profiles - results are the same.

====
This is the NMP checks - the profile that *did not* cause a Master Password prompt.



[Checking the 2.0b1 profile]



C:\Program Files\SeaMonkey>dbpwstate -d "C:\Documents and Settings\gg\Applicat

n Data\Mozilla\SeaMonkey\Profiles\qqm980i1.default"

Slot "NSS User Private Key and Certificate Services" has a non-empty password.



[Checking the 1.1.7 profile]



C:\Program Files\SeaMonkey>dbpwstate -d "C:\Documents and Settings\gg\Applicat

n Data\Mozilla\Profiles\default\3wfogafh.slt"

Slot "NSS User Private Key and Certificate Services" needs User initialization

 It has no password.



[Note that the 2.0b1 profile 'Change Master Password' shows 
"Current password: (not set)" and no Master Password prompt.]



At this point I replace C:\Documents and Settings\gg\Applicat

n Data\Mozilla\ with the profile that initially caused the Master Password prompt.



This is the MP checks - the profile that *did* cause a Master Password prompt.

[Checking the 2.0b1 profile]



C:\Program Files\SeaMonkey>dbpwstate -d "C:\Documents and Settings\gg\Applicatio

n Data\Mozilla\SeaMonkey\Profiles\qqm980i1.default"

Slot "NSS User Private Key and Certificate Services" has a non-empty password.



[Checking the 1.1.7 profile]



C:\Program Files\SeaMonkey>dbpwstate -d "C:\Documents and Settings\gg\Applicatio

n Data\Mozilla\Profiles\default\45582e8v.slt"

Slot "NSS User Private Key and Certificate Services" needs User initialization.

 It has no password.


====
Neil, 
how do the cert and key DBs get migrated from old 1.x to new 2.x profiles?
That should just be a file copy (eventually calling nsIFile::CopyToNative):

http://mxr.mozilla.org/comm-central/source/suite/profile/migration/src/nsSeamonkeyProfileMigrator.cpp#698
I agree with the "should be" part. :)

But the results in comment 32 show that the 2.0 key DB is not a mere copy of
the older 1.x key DB.  Either the wrong file is copied or else some code is 
changing it after it is copied.
Hello everyone,
Been using Seamonkey since 1.0.x on Windows (XP), RHEL3/4/5 and now OSX.
I migrated most of my configs (XPPro SP3, RHEL5 x86_64 and OSX 10.5 on a MacBook Pro) to Seamonkey 2.0b2. I get the same behaviour as described in this bug but on OSX and -not- on either RHEL5 or WinXP Pro.

On my Mac (OSX 10.5.6), SM2.0b2 asks for a master password twice after starting but only when the first page (where a Password is needed) comes up.

I have no idea how everything is stored on OSX but I'm willing to investiguate if needed.
Let me attempt to summarize the questions and issues with this bug.

1) This problem happens to a small number of people who upgrade from SM1 to 
SM2.  We have identified a few things they have in common, but we have not 
yet identified anything that they have in comment that differs from what 
the people have in common who do not experience this.  Are they a small 
percentage of the upgraders?  Or are there just not many who have upgraded 
yet?

2) There are two things we can and perhaps should attempt to do about this:
2a) Identify a quick fix, a simple solution.  
    (Have we already done that to the satisfaction of all the victims?)
2b) Identify why this happens and how to prevent it from continuing to happen
    to people who as they try to uprgade, so that we can prevent it from 
    happening to others. 

To accomplish this latter goal, I think we need to capture a complete user
profile in the pre-upgrade state, and then capture it again in the 
post-upgrade state, just as soon as the problem has been identified.  
Then, developers need to take a copy of that profile and "step through" 
the upgrade process to see where things go wrong.  

Now, if there are any users who have good pristine unmodified backups of 
their SM1 profiles from before they upgraded, and would be willing to 
allow SM developers to experiment with them, that could help a lot. 
 
I don't think we need all (or necessarily any) of your mail folders.
If anyone has such a backup copy of their SM1 profile, who had this problem
after they upgraded, and might be willing to let SM developers experiment 
with a copy of that profile. please add a comment here.
Uhm, when uploading the profile here, wouldn't that expose all passwords? (as the usage of the master-pw is disabled (may there be one or not) they have to be somewhere unencrypted I guess?)
Whoa, don't upload any profiles here!  But if you're willing to share your
old pre-upgrade profile, let us know so we can figure out how best to 
arrange it.
Hi everyone,
While investiguating this bug on my machine last night I noticed the following:

1) I Removed /Applications/Seamonkey.App and replaced it with Seamonkey 1.1.17 (official Build, of course).

2) Went into "1.1.17/Preferences/Privacy & Security/Master Passwords/" to see if I could verify if the Master Password was "(not set)" but much to my own surprise it wasn't!! So I took the decision to 'reset' the Master Password and lose all the passwords.

The thing here is that the 'Wallet' would function fine in the past and let me use the passwords on either SM1.x and SM2.0b2 (albeit on the later the master, the password popup had to be dismissed twice as in this bug report).

I decided to 'reset' the Master Password -from- SM2.0b2 and SM2.0b2 has functionned properly since then without asking for a Master Password.

So I think it may either have been a false positive here (I am sure I didn't set a Master Password but maybe a kid here did) or an artifact of the SM1.x -> SM2.0b2 upgrade.

Now that I know how to restore functionnality (End-Users, ya know), I'll try to see if I can reproduce the problem again on another machine.
(In reply to comment #39)
> Whoa, don't upload any profiles here!  But if you're willing to share your
> old pre-upgrade profile, let us know so we can figure out how best to 
> arrange it.

Feel free to send me instructions via email or similar which steps to take.
(In reply to comment #37)
> Or are there just not many who have upgraded 
> yet?

That is probably the case, as we only have betas out yet, the RCs and final will com in October.
It certainly looks like it's only a small percentage of people who migrate who are seeing this, though.

> 2a) Identify a quick fix, a simple solution.  

I fully agree that would be good for 2.0, esp. as code freeze for that release is due in two weeks.
Maybe I did not see it, but is there a workaround for this if a user experiences this problem and wants to keep his stored passwords?
As I understand it, the reason SM2 repeatedly asks for the Master Password is because it wants to encrypt your previously obscured existing passwords.

So if this is the case, simply deleting your Master Password would work.
Bug 316084 added support for ensuring that the older base64 get reencrypted. This check is done once per session, the first time we try to encrypt or decrypt something (which, in the normal case, is when you'd be prompted for the master password anyway when it's set).
Neil & Justin, 
The problem, as I understand it, is that users who had *NO* Master password 
before the upgrade, but who had passwords saved, now find themselves being
asked for a master password that they do not possess.  

An examination of the NSS key DB in the new post-migration profile shows 
that the key DB is indeed now setup as one that has a master password, but 
the user has never entered one.  An examination of a copy of the old key DB 
file from a backup copy of the old pre-migration profile shows that it did 
not have a master password.

So, the completely unanswered questions are:
a) what step in the migration causes the key DB to be given a master password?
b) what master password is it given?

A related question is: are the stored web site passwords still merely obfuscated?  Or have they actually been converted to be encrypted using a key 
that is now stored in the key DB, protected by the unknown master password?

If the passwords are still merely obfuscated, then they can be recovered.
On the other hand, if they have been encrypted using a key that is now protected by an unknown master password, this is a lost cause, unless we can
somehow determine what value the migration tool is using for the new master 
password that it imposes onto the DB.

Neil, one cannot simply "delete his Master Password".  He could delete his
key DB file, but that would delete the password encryption key that is also stored there. 

Perhaps, as an experiment, he might back up his entire post-migration profile, 
then delete the key DB, mark his prefs.js file to show that he uses password 
obfuscation, not encryption, and then see if he is able to recover the obfuscated passwords.  

I seem to remember seeing a program to recover the contents of obfuscated 
password files somewhere.  It's just base64 encoding.
(In reply to comment #46)
> Neil, one cannot simply "delete his Master Password".  He could delete his
> key DB file, but that would delete the password encryption key that is also
> stored there. 
Sorry, the UI actually calls this "Reset Master Password". The button itself opens a PSM dialog called resetpassword.xul, but I don't know what that does.

> Perhaps, as an experiment, he might back up his entire post-migration profile, 
> then delete the key DB, mark his prefs.js file to show that he uses password 
> obfuscation, not encryption, and then see if he is able to recover the
> obfuscated passwords.
I don't think the login manager reads the pref, even for migration. But if the user wasn't using encryption, I think simply deleting signons.sqlite should trigger a re-import of the obscured passwords.
I believe that "reset master password" also erases all previously stored 
passwords, clearly NOT what the user wants to do in this case.

isn't signons.sqlite where the encrypted/obscured passwords are stored 
in the new profile?  
Is the old file, where they were previously stored, still kept around?
(In reply to comment #48)
> I believe that "reset master password" also erases all previously stored 
> passwords, clearly NOT what the user wants to do in this case.
But the lack of the correct master password would presumably have caused the encryption to fail, so there would not be any stored encrypted passwords.

> isn't signons.sqlite where the encrypted/obscured passwords are stored 
> in the new profile?  
> Is the old file, where they were previously stored, still kept around?
I believe so, unless you choose to delete all passwords. And of course the original profile's version of the file still exists.
We don't know how the key DB with a master password came to be created, 
but it did, so presumably a master password string was taken from somewhere.
Maybe it was a random string.  Maybe a string from a URL or a preference.
Who knows?  Maybe even an empty string (although users have tried that 
without success).  But some string was definitely used to create that DB,
and the passwords could have been (likely were) encrypted at that time.
(In reply to comment #50)
> the passwords could have been (likely were) encrypted at that time.
Or possibly not, according to comment #0 and your quote in coment #10.
Hi everyone, After migrating all of my home machines to the Seamonkey 2.0 family and using them over a little over two months, I think (IMHO) that I have collected a little more data on this issue:

- I've been runing Seamonkey on Linux, Windows (and MacOSX since '07) since version 1.0 came out. Before that, I used Netscape 6.x, then 7.x.

- In all cases, a Master password was -never- set by any home end-user either on Linux, Windows or MacOSX.

- When the 2.0bX, 2.0rcX and 2.0 versions started to show up, I started to test them and that's when I first came accross the issue described here.

- Not all platforms exhibited that issue: sometimes, after the 2.0* upgrade, the Master Password remained 'Not Set' but on some platforms (first noticed on OSX), the #506638 issue occured.

- On a few identically-patched RHEL5 x86_64 platforms things were more mysterious: the issue didn't occur on the first platform (where the end-users home directories had been created recently: i.e in 2008), but it occured on the latter (where the end-users home directories were in frequent use since '97). Also, in all cases, this was with the exact same Seamonkey 2.0.x binary rpm build.

- I think that the platforms where I saw the problem occur are mostly the computers where the seamonkey distribution hasn't missed an update (up to 1.1.18) since the 1.0 times. Let me explain:

* Platform A is new and used infrequently, it was initially installed with RHEL5 and seamonkey-1.0.9. Active end-user on platform A doesn't have an issue with the master password when he's upgraded to SM2.0.

* Platform B has been running RHL6.2, then 7.2, 7.3, then RHEL 3.0, 4.0 (i686) and now 5.0 (x86_64). On platform B, the end-users homes were migrated when the distribution was upgrade. Platform B is used frequently and is updated often with RHN.

At the time of the SM2.0 upgrade, both platA & platB were running the same RHEL patchlevels and SM1.1.18 but the Master Password issue occured only on platB (where the home directories had seen a -lot- of system upgrades and Seamonkey updates).

While investigating how I could retain the 'Not Set' status of the Master Password on platB without loosing all her passwords, I came accross this post:
http://forums.mozillazine.org/viewtopic.php?f=38&t=518590&start=0

I did this:
* I downgraded platB to SM1.1.18
* I removed the SM2.0 directory in the end-users' $HOME/.mozilla/seamonkey (to loose track of the previous 1.0->2.0 upgrade).
* I removed the key3.db from the user's SM1.0 profile (It shouldn't be there anyway since the Master Password was never set, right?)
* I upgraded platB back to SM2.0 (I think it was RC1).
*** This time it worked and end-users master password was 'Not Set' in SM2.0.

So, here's what I think happened (please excuse my less-than-technical description): 
Over the course of the 1.0.0 to 1.1.18 releases, at some point a wrong key3.db file was created even when the end-user hadn't set a Master Password. Of course, when SM1.x gets upgraded the SM2.0 grabs the key3.db file and thinks a Master Password is set. On platforms which don't see an end-user often, the problematic SM1.x release was perhaps 'skipped' and the key3.db file was never created, thereby resulting in an eventless SM2.0 upgrade.

So perhaps the workaround is simply to delete the key3.db file before upgrading to SM2.0 when you are certain that no Master Password was set?
> I came accross this post:
> http://forums.mozillazine.org/viewtopic.php?f=38&t=518590&start=0

That post contains a statement that the key3 DB contains the key that is
used to encrypt web site passwords (which is correct, when web site passwords
are being encrypted) and that this key *IS* the "master password".  That 
latter part is incorrect.  They key3.db does not contain the master password.
The master password is not the key that encrypts web site passwords.  It is
the key that encrypts the contents of the key3.db file (when the key3.db file 
is encrypted).  The only place it is stored in in your head.

> * I removed the key3.db from the user's SM1.0 profile (It shouldn't be there
> anyway since the Master Password was never set, right?)

Sorry, wrong.  It should always be there, even when no master password is in 
use.  I'm sure that when you completed the upgrade, you had a new key3.db 
file in your upgraded profile directory.  That new key3.db file was not set 
to show that it was encrypted with a master password.  

The key3.db file is used to hold other things besides the key that encrypts
the web site passwords.  Removing it will remove all those other things also.
If you don't have any of those other things, then it's fine to remove that
file.  That was evidently your case.  Probably a lot of users are in that 
situation.  But I'd advise renaming it rather than deleting it, just in case.

In the past, we've had users who claimed to have had backup copies of their
old pre-migration key3.db files, and they've sent us copies of both their 
pre-migration and post migration key3.db files.  IIRC, upon examination
we found the old file to be a perfectly ordinary key3.db which was not set 
to be encrypted with a master password, and the newer file was an ordinary 
appearing file that was set to be encrypted with an unknown master password.
In every case, it remains a mystery how & when that conversion too place.
(In reply to comment #53)
aaaaaa
> In every case, it remains a mystery how & when that conversion too place.

FWIW, the only code in login manager that does anything with the master password is in toolkit/components/passwordmgr/src/storage-mozStorage.js init() [and the similar function in storage-Legacy.js]

222       // Check to see if the internal PKCS#11 token has been initialized.
223       // If not, set a blank password.
224       let tokenDB = Cc["@mozilla.org/security/pk11tokendb;1"].
225                     getService(Ci.nsIPK11TokenDB);
226
227       let token = tokenDB.getInternalKeyToken();
228       if (token.needsUserInit) {
229           this.log("Initializing key3.db with default blank password.");
230           token.initPassword("");
231       }

This was inherited from the older Firefox password manager, which has been around forever.
Hi Nelson, thanks for correcting my post.
(In reply to comment #56)
> FYI, we're seeing a fair number of reports of this issue for Thunderbird 2->3
> upgrades as well:
> http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla:en-US:official&hs=U9e&q=+site:getsatisfaction.com+get+satisfaction+master+password&ei=IH9HS4LvHIvssQO0rKj1Dw&sa=X&oi=nshc&resnum=1&ct=more-results&ved=0CA8Q2AQ
> 
> We probably want a shared bug.

yes definitely a thunderbird 3 bug:
1. 27 people had it in this gsfn thread (although sometimes users get it wrong and this thread started back in the 2.0.0.23 days so the count is a probably a wee bit lower say 20ish)
http://getsatisfaction.com/mozilla_messaging/topics/password_problem31

2. 6 people had it in this thread:
http://getsatisfaction.com/mozilla_messaging/topics/where_do_i_get_a_master_password

workarounds that have worked for users:
1. Tools -> Error Console -> paste openDialog("chrome://pippki/content/resetpassword.xul") ->click "Evaluate"
2. delete the key3.db file
Whiteboard: [gs]
Flags: blocking1.9.2?
Not a release blocker as I understand it, we can fix in a 1.9.2.x, right?
Flags: blocking1.9.2? → blocking1.9.2-
Whiteboard: [gs] → [gs][3.6.x]
I think I hit this bug in TB2 > TB 3 migration because, although my passwords were unencrypted I /did/ have personal certificates. When during migration it asked for my 'master password' I was surprised because I never set one, but I tried what I've always called in TB (and SM before that) the 'security device password' and it worked. I don't think this cause of this bug has been mentioned here.

(But I didn't and don't want my passwords encrypted in TB3 - see bug 534444 which is /not/ a dup of this.)
The 'personal certificate' aspect is interesting.
Since reading your post, I started wondering if it could have it me too.

I -think- that my SM1->SM2 'master password' issue occured like you describe on installs where a 'personal certificate' was installed. I using exactly -one- personal certificate and it wasn't propagated to all of my SM1/SM2 installs; it was only present on a couple of them and I -think- the above issue occured only where the certificate was installed.

(Of course, I did have an empty master password in all of SM1 installs, BTW).
In reply to comment 59, 
the terms "master password" and "software security device password" are 
synonymous.  They're the same thing.  If I recall correctly, the 
"security device" term was used before the Mozilla browser split into 
Firefox and Thunderbird, at which point the "Master Password" term came 
into use.
(In reply to comment #61)
> In reply to comment 59, 
> the terms "master password" and "software security device password" are 
> synonymous.  They're the same thing.  If I recall correctly, the 
> "security device" term was used before the Mozilla browser split into 
> Firefox and Thunderbird, at which point the "Master Password" term came 
> into use.

True-ish - but as a user who used NS then SM then TB2 they weren't obviously the same.

The TB2 options included "Use a master password to encrypt stored passwords". I didn't do that.
When I encrypted an email it said "Please enter the master password for the Software Security Device". (Note the capitals.)
So it looked to me like two passwords - the master password for encrypting stored passwords and the Software Security Device password. Just explaining it from a humble user's point of view. 

It's why it appeared to me that these 'two passwords' had been combined in TB3 - hence my wording in bug 534444
i upgraded two win32 (winxp) thunderbird 2.0.0.24 installations with four separate pop3/smtp accounts (all in the same single/default tb profile though) to 3.0.3 in the first step via the normal check-for-updates (help menu) function.


3.0.3 upgrade was offered first. after restart of 3.0.3 it immediately asked for a master password (although never even having come close to master password functionaly in the past with tb 1.x and 2.x) several times.

i had to cancel these master-password dialogboxes.

all my passwords were protected (invisible) now in the options / security dialog box and it also asked for some of the pop3 passwords as well.

the following update from 3.0.3 to 3.0.4 via the same check-for-updates method didnt help either.

this has happened for two 2.0.0.24 (winxp/win32) clients, almost exactly the same way. the only thing that both clients were using regarding to passwords, was the simple password saving functionality (password manager) from tb 2.x for the pop3 and smtp passwords. nothing else.


so eventually, i had to reset all of my passwords via the "openDialog("chrome://pippki/content/resetpassword.xul")"  method described in getsatisfaction discussions and other places, but all of my password data was lost this way.

this is ridiculous and completely unacceptable.
my other client that also went from 2.0.0.24 to 3.0.3 was experiencing the same problems. the passwords were locked away behind the supposedly needed masterpassword.

on this other client i tried this other recovery method by deleting/renaming the key3.db file in the profile directory.

after this step the thunderbird 3.x client wouldnt ask any more for the master password and the password dialog would also display the password column again as well, with the saved passwords there. so far so good, but when actually fetching pop3 mails with this client it would never the less ask for pop3 passwords.

the password popup dialog would come up and ask me for all my four pop3 accounts during fetch-new-mails and i can then again mark the checkbox that it should save these newly entered passwords again with the password manager.

this is really weird, and i cant really see any difference now when i go into the saved password dialog box.

new or additional entries with username/password columns seem to show up in the password manager, seem to be duplicated but with exactly four lines now lacking the username, only having the password column filled, but displaying empty username passwords.

additionally after having entered the pop3 passwords again during the pop3 access for all the four pop3 accounts, the password manager displays properly four completely filled entries having username data and password data as well.

i am unsure though which entries were still the old corrupted ones and which ones got refreshed (an additional datecode column would actually make sense for debugging means to be able to tell when a credential entry has been exactly generated, created or even been accessed the last time.


so i am wondering why it asks me for pop3 passwords although it should be able to lookup find and use the already saved passwords that are at least being shown in the gui.

on this first 2.0.0.24 to 3.0.3 client where i only used the resetpassword.xul line in the error console, had lost all the credential data as i wrote before, and now that i re-generated the credential stuff, now displays exactly four entries for pop3 credentials, fully filled with username and password columns and nothing else.

btw, all my 3.0.3 clients then were updated to 3.0.4 but the masterpassword problems were still present, before i tried this resetpassword.xul and the key3.db stuff.
This bug should be moved to either MailNews Core/Security or a Core component
as it doesn't appear to be specific to SeaMonkey. Can someone covering Core move this into the correct component?
The status of this bug is still "unconfirmed" and it has been assigned to "nobody."

So how can it be moved to MailNews Core/Security or a "Core component"?
As far as I'm concerned, it is confirmed because my desktop Ubuntu 9.10 email is dead until I can get a fix.
Re comment 65 2010-04-07
I can confirm the bug (#506638)in Windows Vista with ver 3.1.2 thunderbird
I was able to bypass the master password with a "Rename" of key3.db, and get the email to work again, BUT all my old web site passwords are locked in to the old renamed file (i used key3old.db for the rename). I was NOT able to get thunderbird to display the saved passwords in key3old, it only found the new passwords to my email servers that i manually put in the "new" key3.db that was evidently created after thunderbird was restarted after the rename. So i still need help to get my old passwords from web sites reinstated from key3old.db to key3.db. Would appreciate abittner to clarify comment 65.
This bug occurred on OSX 10.6.4 during an upgrade to 3.1.2; this is the first time I have seen the new GUI look, so it is probably my first use of 3.x [my prefs.js has:  user_pref("extensions.lastAppVersion", "3.1.2"); and my system backup shows "2.0.0.24".]

The upgrade happened when I was typing in another window and Thunderbird asynchronously grabbed the focus and interpreted my keystrokes as approving the install (accidental dialog approval for one-way trips should never happen.)

This problem was discovered almost a year ago and is still happening?  

Cost to me:  A waste of about 3 hours, and I still need to setup up passwords again for 6 accounts.
This problem occurred to me when I upgraded my LINUX OS to Ubuntu 10.04 LTS from Ubuntu 8.04 LTS. I was previously on Thunderbird version 2.xx and am now on 3.0.6

As the upgrade was unplanned, I do not have a backup of the Thunderbird files from before the upgrade.  I have been using  Thunderbird/mozilla/netscape/...  "forever" and have NEVER set a master password.  I did have a personal certificate from some time back...

Immediately after the upgrade I started getting prompted for "master password" and without thinking entered the one that I commonly use for some email accounts.

It allowed me to continue, without problems. 

After spending many hours researching how people "fixed" this issue and noting that deletion of the file would cause Thunderbird to lose existing email passwords, I opted to "remove" the password. Which I did, and it seems to be working. (I have MANY email accounts, so I'm not totally sure at this point.)

I know this is not going to help people who do not KNOW what the password is, but I guess I just got lucky.
(In reply to comment #71)
> I have been using  Thunderbird/mozilla/netscape/... 
> "forever" and have NEVER set a master password.  I did have a personal
> certificate from some time back...
You would have been prompted to set a master password when you installed your personal certificate. If you had not used it for some time, then you would not have needed the master password and may even have forgotten that you had one.
Good point and probably true.  If I had been asked to create a master password, I would have probably used the one I entered.  From my standpoint, it is interesting that I have "never" been prompted for it until after the upgrade to Thunderbird 3.0.6

If this change in behavior is actually intended by the developers (where I as the user have to enter the master password everytime I want to check my emails), then this behavioral change should be explained to the user during the upgrade process, giving the user the choice to "remove" the password at that time - or giving them the option to "reset" it with the knowledge that they might have to change account passwords... 

Anyway, thanks for the chance for me to say my "2-cents" worth.
so whats the progress regarding this bug (although i have only come across it with thunderbird, as i am not using seamonkey at all).

this is more than just a showstopper to me, a complete blocker or how you guys might call it, as it seems that as far as i have understood nobody at all has come even close to figure out how out of a sudden a masterpassword is blocking the user and locked away parts of his/her information which actually means a complete dataloss in my opinion.

nobody knows when this bug will strike again maybe again when thunderbird or the core parts move from 3.1 to 3.2 or whatever the real deep source of this bug might be.

i cant really recommend thunderbird to just anyone with bugs such as this. not unless the users keep track of their username/password/credentials stuff out-of-bounds aka outside of the thunderbird application in addition in case this bug strikes again and locks away all the previously saved credentials inside the deep catacombs of the thunderbird/seamonkey apps :(

ab.
(In reply to comment #74)
> nobody knows when this bug will strike again maybe again when thunderbird or
> the core parts move from 3.1 to 3.2 or whatever the real deep source of this
> bug might be.

There were some big changes of functionality between 2.0 and 3.0/3.1 which have appeared to cause this in a few instances. Those sort of changes would be highly unlikely to occur again, and if in the rare chance they did they would likely be better understood and caught early and more easily fixed.
How do I delete Thunderbird 3 and reinstall Thunderbird 2?
God damn it, this is a bug report! 
Ask in the correspomding newsgroups or support forums for help.

@Developers: Can I consider this issue as WONTFIX? 
In that case I'd be happy to get my email-address removed. (if this is possible at all as I'm reporter of this bug and obviously can't do it on my own)
Setting to NEW as clearly a number of people have seen this, even though we have no explanation or fix.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: 381269
Do the versions of SM2 that experience this problem contain the fix for 
Bug 437904  ?   I was optimistic (er, at least hopeful) that that bug fix 
would also solve this problem for people who upgraded SM1->SM2 using a 
version with that fix in place.
(In reply to comment #80)
> Do the versions of SM2 that experience this problem contain the fix for 
> Bug 437904  ?

In what 1.9.1.x version did that land?
This bug is also present in the latest Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.4) Gecko/20100608 SUSE/3.1.0 Thunderbird/3.1

Severity should be changed at least to "major". This is a) very annoying b) very old c) there's no workaround present except deleting the master password at all which could be a severe security risk.
Do you mean there is no cure for this? Suddenly I started having this problem after having 3.1.0 TB in Mac OS 10.6.8, tho it worked fine for months. I cannot receive my email, except randomly when it decides to every several days. It is VERY ANNOYING to have to use my webemail, as I like to save all of my emails in ONE place, in Thunderbird, not web based email. I archive email for our whole family and need to get this figured out. TB KEEPS asking me for password, but never accepts the one or lack of one I have set up in Preferences>security>masterpassword. I get error: Login Error. Cannot login to Hawaiiantel.net. Or, Alert, Error getting mail password. Please help someone! I tried deleting key3.db and that didn't work either.
Blocks: 521648
Why don't we drop this and save space?  I have given up I have a text file that name is the password.  I just copy the name and paste into the password window.  That is the work around.  I initiated this bug.  It was several versions of SM ago.
This bug is still active.
Person on forum just updated to version 17.0.4 and suddenly is being asked for a Master Password that was never set.
Tried removing key3.db, but this does not work.
One very unhappy Thunderbird user:
https://getsatisfaction.com/mozilla_messaging/topics/password-cq7v9
No longer blocks: 521648
See Also: → 521648
Anyone see this in the past year??
No and it also no longer a supported upgrade path so lets kill the bug for now.

Please reopen or better open a new bug if you experience this with current SeaMonkey 2.x versions.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
(In reply to Frank-Rainer Grahl (:frg) from comment #88)
> No and it also no longer a supported upgrade path so lets kill the bug for
> now.
> 
> Please reopen or better open a new bug if you experience this with current
> SeaMonkey 2.x versions.

agreed, should be closed, haven't see this for years on my distros rpms (OpenSUSE Leap 15 currently)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: