User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040514 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7RC2) Gecko/20040514 Users should have options to block brute-force attacks on their master passwords. One option should be that the Password Manager would refuse to operate after a user-settable number of consecutive unsuccessful attempts to enter the master password. The other option would be a user-settable elapse of time after which the Password Manager would again permit operations. Both options would require the user to input the master password before setting or changing. Having either option unset would disable the feature (there being no default values). Reproducible: Always Steps to Reproduce: In some operating systems that require a user to logon with a password, three consecutive wrong passwords lock the user's account. In some systems, it takes a system administrator to unlock the account; other systems, it takes the elapse of time (e.g., two hours). Rather than hard-coding the number of failed attempts or the time-out, these should be user-settable. Note: Bug #232050 should be implemented with this enhancement so that the frequency of typos ("fat fingering") would be reduced while entering master passwords. Then, this enhancement would less likely be triggered accidentally.
this is pointless. i can make 100 copies of the master password file and build my own specialized master password attacking program. my program would ignore any such restrictions one might try to enforce. no one (even a brute!) in their right mind would try to brute force using the standard seamonkey xul. it takes way too long.
QA Contact: jrgmorrison
Comment #1 indicates a severe weakness in the design of the Password Manager. Rather than storing the master password, it should be used in the same manner that the passphrase is used in PGP. Anything protected by the master password should be encrypted by using a standard hash function to create a key that is then used by a symmetric encryption algorithm. When a protected item (e.g., an individual password) is used, the same hash function and encryption algorithm is applied to the user-entered master password to decrypt the item. So that the user does not have to re-enter the master password repeatedly during a session, it can be in a memory-only cache (as with PGP) that is deleted upon switching profiles, exiting, or crashing. If this is not the security model for using the master password, you have a major security flaw. Storing the master password on my hard drive provides only marginally better security than not using a master password at all.
(In reply to comment #2) > Comment #1 indicates a severe weakness in the design of the Password Manager. > Rather than storing the master password, it should be used in the same manner > that the passphrase is used in PGP. Uh, it _is_ used in such a way to the best of my knowledge. how does comment 1 contradict it?
Response to comment #3: Comment #1 indicates that the master password is contained in a file residing on my hard drive: "i can make 100 copies of the master password file". The purpose of the master password should be to secure my list of individual passwords, protecting me if someone else accesses my hard drive. If the master password itself is on my hard drive, that means a hacker only has to copy two files instead of one and then attack the master password at leisure on his or her own computer. In this case, the added protection granted by the master password is merely the extra time I might have (while the hacker resolves the actual master password) to discover the attack and change all my individual passwords. If I don't realized I've been attacked, that is scant protection.
(In reply to comment #4) > Comment #1 indicates that the master password is contained in a file residing on > my hard drive: "i can make 100 copies of the master password file". oh, I'm sure timeless meant the file with the encrypted passwords.
i'm not saying that the password is stored on disk, i'm saying that i can attack the thing that does the validation without using seamonkey. any mechanism you suggest to prevent the brute force attack will fail since i can simply roll back to the version of the file from before my attack started, or just skip the code entirely. blocking is only useful if it lives in a place which is more privileged than the place where normal stuff lives. this is the case for remote servers and system processes. this is generally not the case for mozilla. as to your latest comments, this is generally how encryption works. encryption is used as a way to protect data for a limited time (limited by the strength of the cipher). the stronger the cipher, the longer it takes to brute force using resources available at the time the cipher was used. but there's generally nothing preventing someone from taking the problem off your computer and putting it into a much more powerful computing cluster. you pgp file is indeed not more protected than my password file for the same reasons. -- note: the master password system used by mozilla can relate to a hardware device which is like the privileged system i described above, and in fact such a system probably can have a way to lock itself after too many attempts. in the hardware case, the data is not portable and is relatively safe. -- note: my cell phone's master password system is better than the pgp/general password system which seems to worry you. when you create a master password, it asks for a second piece of info which it encrypts with your password. when you log in, it shows that info decrypted for a short interval. the device then lets you browse through the rest of the decrypted items. note that my cell phone never knows or says that the password entered is wrong. the user has to verify that the feedback from the cellphone is correct.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.