> There have been way too many products pushed out failed utterly and abandoned by mozilla in the last few years.

Have there? Off the top of my head there's Persona and Firefox OS, the latter of which Mozilla kept trying to push on with long after the rest of the world had concluded it was doomed. Meanwhile we got Rust and Focus out of Mozilla.

There was abloginnservice before persona iirc. Firefox hello. thunderbird.

I'm sure there are more, but those come to mind imediately.

Firefox Hello stands out to me as another case of Mozilla stubbornly trying to make something work for much longer than anyone on the outside would have advised. It started as an intern project to demo WebRTC and persisted for 3 years amidst incessant predictions of its doom.

Thunderbird has received continuous development and maintenance for coming up on 15 years since its public release.

>thunderbird

Not abandoned, i'm using it, i'm happy with it, thank you very much.

It's not developed by Mozilla anymore though.

It's a community project now. So yes, is is abandoned by mozilla.

It's more complicated than that. Mozilla is financially sponsoring Thunderbird, and helping to aid in development.

I'd love for them to do more, but I understand why local mail clients aren't a growth area.

https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-fu...

1. Browsers are expected to have password management of some sort. Firefox's existing one is rather inadequate from a UX and security standpoint, as recently discussed.

2. Browsers need to be trusted and secure. If you use Firefox, you are trusting Mozilla et. al. to have the policies, procedures, motivations, and expertise to create secure software that protects your privacy. If you can trust them to make your browser, you can trust them to make your password manager.

I do hope that Mozilla answers these questions directly when/before this moves out of beta.

1. Yes but that doesn't answer the standalone question.

2. I do trust Mozilla to have the technical expertise to build a secure password manager. But just because they can do it, still doesn't answer why they're doing it the way they're doing it.

I would just like to hear Mozillas thought process that went into this. I'm sure they have reasons for all decisions, but I can't read thoughts.

Knowing their thought process would help me evaluate my prediction of this being abandon-ware in half a year.

> Browsers are expected to have password management of some sort. Firefox's existing one is rather inadequate from a UX and security standpoint, as recently discussed.

I'd like to see this discussion.

For me, I find Firefox's password manager the only one I can bother using, because it offers a good and seamless UX, right where I need it.

If they "fix" that by making it terrible like Lastpass, I honestly don't know what I'll do.

> I'd like to see this discussion.

Concerning the "security standpoint", probably this news [0] is meant. Hashing the password with SHA-1 using 1 iteration may be referred to as "inadequate".

[0] https://www.bleepingcomputer.com/news/security/firefox-maste...

Maybe if the hash were actually being stored, as in a website's accounts database, but SHA-1 is being used here to normalize a variable-length user-supplied password into a fixed-length string which can be used as the key input to an encryption function.

The article approaches this from an angle of an attacker with access to this hash bruteforcing it to obtain the original plaintext password. But as the hash is the encryption key, if an attacker were able to recover it from the encrypted password store blob, it would already be game over.

Applying a more costly hash algorithm would increase the cost of generating guessed encryption keys in a bruteforcing scenario, strengthening weak passwords somewhat. But using a single SHA-1 iteration here doesn't weaken the password security model. A strong password will remain strong.

> 1. Browsers are expected to have password management of some sort.

Having a browser component that can be asked by other browser components to pretty please fill in some secrets seems like a way to increase your attack surface. With an external password manager and no integration there's no internal API to be exploited, short of compromising the whole user, or if you have some sort of application isolation, the whole system.

I've been using KeeFox (now Kee) and I like it. It's not perfect, but it works well with KeePass. That, along with Dropbox syncing, and the app Keepass2Android make it my preferred method for password management.

KeepassXC browser integration actually works well.

The KeepassXC browser plugins do not work on many websites. It is absolutely not comparable to the quality of the 1Password plugins. Currently I am testing Enpass, which works well so far.

…if you keep KeepassXC open in background and unlocked. Bad UX for me.

Same concern here, that's why I made LockyWindow for Keepass (original). It's a shame there isn't a way to use an interchangable format at the OS level for Macos Keychain, Gnome Keyring, Windows crypto, etc.

And not totally clear that it's a (official?) Mozilla effort.

It’s an official Mozilla effort, given that it’s discussed as a key item in our roadmap update four days ago.

Keepass does not provide anything to sync passwords between devices which seems to be an important part of Lockbox.

If anything, I would have said that KeePass provides too many ways to sync devices...

KeePass has a feature to sync two files, and can access a variety of network storages. That's not one turn-key solution, but it covers just about everything. Meanwhile I simply store the file in my Dropbox because I don't do concurrent edits and it's slightly more convenient that way

Yes but does it sync with Firefox browser directly on Android? I'm using Keepass2Android which is not that convenient. Direct integration in the browser like what Mozilla is doing would be better.

Agreed. Dropbox + KeepassXC has been a great combo for me.

>Dropbox

Honest question, but pushing your KeepassXC db into Dropbox shouldn't raise some red flags from a security perspective ? If "somebody" gets your encrypted db, they can rainbowtable the crap out of it to unlock it.

To me it seems by using Dropbox you just add another sizeable attack surface.

To me the entire point of a password manager is to solve password reuse. I can only remember a small number of high-quality passwords. I use one of those to secure my password manager, and I consider that password good enough to be unbreakable even if stored with a simple unsalted hash (and I know KeePass does much better).

I would be comfortable hosting my password file publicly. Any benefits from Dropbox authentication are just defense in depth (and privacy benefits).

They can't. Keepass uses a Salt (and Nonce) for the key derivation. Modern settings also include Argon2 (which I have enabled for my DB), which excludes everything but CPUs from efficient cracking.

The DB attack surface is to some extend expected to be eventually obtained by an attacker. As long as your master password is nice and long, they "can't do shit" for a long long long while.

True, and SQRL has a similar weakness. Keepass does offer some choice in rounds and algorithm. So that can offer some protection.

I don't see how Dropbox is related to rainbow tables - presumably KeepassX uses a salt.

What? Just look up Keepass2Android etc.