On Wed, Oct 14, 2009 at 12:23 PM, Nelson B Bolyard <nel...@bolyard.me> wrote: > On 2009-10-14 11:37 PDT, Honza Bambas wrote: >> Nelson B Bolyard wrote: > >>> By the way, I REALLY REALLY wish that the password manager would use that >>> when you click the button to reveal the passwords, instead of doing what >>> it does now, which forces you to re-enter the master password, even if >>> you've JUST entered it. >> >> Isn't it just the protection? How should the software recognize that in >> 10 seconds after I entered the master password there is not another >> person that tries to see all my passwords? > > As you know, the user can configure the amount of time after he enters > his master password before he is automatically logged out, and must > re-enter it. It can be configured to be infinite (ask only once), or > ask every time, or ask after so-many minutes of time have elapsed. > > I'd say that, when the user has chosen a number of minutes, we should > honor that, and not ask him to re-enter his password more frequently > than that. If the user has chosen infinite (which is the default for > Firefox) then in that case, I think it's reasonable to ask him for it > again before revealing passwords, even though that's more frequent than > he has specified.
For a view from the Apple camp: When in Keychain Manager, I can unlock the entire keychain (and this is typically done on login, if the keychain password is the same as the login password). However, this only allows for the contents of the keychain to be enumerated, and applications which have previously been authorized to access certain entries are allowed access to those things they've been authorized for. Keychain Manager lets you get the properties of any "Internet Password", "Application Password", or "AirPort Password" item, but it will not show the password by default. If you ask to see that particular password, it will prompt you for the keychain password in order to authorize it. The reason is that otherwise, someone could log into their box, let their friend use it, and friend can then see all their passwords. In the absence of the ability to unlock anything via cryptographic or biometric devices, the master password is the only line of defense. Administrator Manate doesn't exist for most home users, and due to the risks of even a single breach (some banks still allow their signin passwords to be saved, and I know that my phone company does -- both things that push the burden of security onto the user) I think that it's reasonable to require the entering of the master password. I also think that it'd be reasonable to only show the password for the currently-selected entry in the box. However, I'd prefer to see a means of locking the softoken if a secondary (possibly hard) token/key isn't available. (yes, I know that this sounds completely confusing -- but single sign-on doesn't happen overnight, and it's going to take a while for everything that's security-sensitive to work its way over to it.) This would allow me to, say, lock my Apple keychain (once the Keychain PKCS#11 Token driver is written) and then, because a key that is in it wouldn't be accessible, it would prevent access to the passwords stored in my Mozilla profile. Anyone who's read any of my diatribes about how Firefox's crypto-related screens do more to drive users away from security than to embrace it knows that I am loath to suggest the idea of forcing people to go through any additional screens or pop-ups... but this one, requiring the master password (which I'd, again, like to see more like the "Master Credential") before showing the requested password from Mozilla's store, I really have no choice but to agree with. (As I continue on this train of thought, I find myself near where Microsoft did when they created their User Account Control setup... except that I wouldn't make it an ivory tower of defense that administrators need to change their habits to accommodate, rather a bunch of fiefdoms with small clusters of programs being able to make changes within each. But, that's another rant.) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
