244190 - Prevent Brute-Force Attacks on Master Password

Status: RESOLVED EXPIRED

(SeaMonkey :: Passwords & Permissions, enhancement)

Description

[David E. Ross]

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.

Comment 1

[timeless]

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.

Comment 2

[David E. Ross]

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.  

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

(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?

Comment 4

[David E. Ross]

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.  

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

(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.

Comment 6

[timeless]

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.

Comment 7

[Gervase Markham [:gerv]]

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/

Comment 8

[Gervase Markham [:gerv]]

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.