Hacker News new | past | comments | ask | show | jobs | submit login
Firefox Lockbox (firefox.com)
261 points by sahin-boydas 9 months ago | hide | past | web | favorite | 153 comments

I installed it and will compare it to Lastpass (which is pretty good IMO). HOWEVER, it saddens me to read on the front page: "using 256-bit encryption". I'd really expect the competent people at Mozilla to know that this statement means next to nothing. At the very minimum I want to know:

1) HOW is the key derived (say, "derived used PBKDF2 on the Firefox username + password")

2) WHERE is it encrypted (I assume "encrypted on the device/end-to-end/zero-knowledge"). It needs to be clear what the attack vectors are.

3) HOW is the secret managed (say, "Secret is wiped on all application switches")

and probably more that I forgot.

Using the app, the first thing I noticed is that I have a LOT of duplicate entries but no obvious way to clean that up.

EDIT: I see most of these details are on https://blog.mozilla.org/services/2014/04/30/firefox-syncs-n... but it doesn't change my disappointment in the totally useless "256-bit encryption" statement. Just say "strong encryption practices" and provide a link to the details. 8,192 bit encryption doesn't help you if you don't manage the key well.

Firefox Lockbox architect here. Thank you for the feedback. Your comment is fair; we can, and will, do better on the details. The language we have today is the balance marketing, security reviewers, and engineering could reach for the masses to feel informed without being overwhelmed and confused.

As you found, Firefox Accounts derives the encryption key from your username and password on the client-side; the server is never aware of your password. That encryption key protects your data on your device using AES-256-GCM, and is stored in its security enclave behind Touch ID or Face ID wherever possible.

>The language we have today is the balance marketing, security reviewers, and engineering could reach for the masses to feel informed without being overwhelmed and confused.

It would be fantastic to have a 'more details' page, where the nitty-gritty is detailed for those who care.

Thanks for this, and wanting to know more! We're working on expanding our docs to add this.

Maybe also compare this service with other cloud password managers. It's not easy to understands the pros and cons of each of them. Is this a better service than existing managers and if so, in what way?

I, too, want to know the implementaion details. That said I’ve watched hundred of eyes gloss over as I emphatically implored lay-persons about password policies and tools like password managers and Frankly their definition of ‘secure’ can be encapsulated in ‘256-bit encryption’.

An oversight on Mozilla’s part for security-types and engineers, but maybe they have the masses in mind with this tool & it’s marketing site.

Maybe the ship has sailed, but I would prefer laypersons not associate the phrase "256-bit encryption" with anything, and would much rather one like "strong encryption practices" if it's a link to the technical specifications. They have no basis on which to evaluate what 256 bits of anything actually mean, so using it as a technical term to throw at their face intending for them to latch onto it as a valuable metric is actively harmful. What if it said "Strong 256-bit RSA encryption". To you and I that phrase should send off alarm bells, but a layperson might actually rank that as more secure because of the added technical jargon. You've just taught them to trust random technical-sounding security jargon so adding more jargon makes it sound more better.

It's probably way to late to make any difference here, but I still wish mozilla could push the boundaries here.

On the other side, is it fair to say 8-bit encryption is NOT secure?

yeah, but if I'm rotating a 256-bit key using XOR, is that really secure? It's 256-bit encryption, but about the weakest thing I could possibly do short of plain text.

Do the masses have any idea of what "256-bit encryption" would mean anyway?

Not at all! But that’s what all the other security whitewash on financial and ecommerce sites say, so to most folks it, like, totally means it’s really really secure— pinky swear!

I'd guess for that page the technical details get fed to marketing who boil it down to whatever they think will impress people with limited (if any) technical knowledge.

Exactly that, but shouldn't we expect better from Mozilla?

For Mozilla to be successful they have to appeal to the largest demographic possible. I'd only ask that Mozilla make additional technical information easy to find and well laid out.

This is LastPass's page:


But that too you won't find when you use the app/extension normally.

Mozilla can do a lot of things that harm users or the general public but increase its success. Mozilla shouldn't do these things.

This neither harms users nor the general public, so I don't see relevance.

If by PBKDF2 you mean PBKDF2-HMAC-SHA256, it should die as it's so much less secure than using Argon2 as a password hash function.

I'm disappointed.

Instead of making password management modular, so any password manager capable of certain queries and operations (KeePass, LastPass, Bitwarden, KWallet/Gnome Keyring/libsecret, Microsoft Credentials Management API, Apple Keychain, etc) could become a storage backend with some programming effort... they're doing the exact opposite - they've created yet another password manager UI and yet another proprietary data format (Lockbox Data Storage) for that purpose.

Seriously, I doubt many (if anyone) but Mozilla management needs or wants a Mozilla-branded extra ecosystem, in addition to Google, Apple and Microsoft-branded ones - yet another piece of software that doesn't interoperate with anything but its own unique data formats and protocols.

I don't know what others want, but I want a good browser that I can hook up with things I already use.

We either have different definitions of proprietary, or I'm misunderstanding something. The format appears to be open and documented. https://github.com/mozilla-lockbox/lockbox-datastore

Different definitions, I guess. I call it proprietary because it's:

- Unique to Mozilla products. Invented there (disregarding any existing solutions of the same problem) and no one else uses this.

- Based on Accounts and Sync I believe this is not a standard at all, just something that happens to be documented. With FxA&Sync there are a lot of undocumented subtleties and things sometimes change at whim without any warnings. If you make an independent implementation, you're bound to be always catching up, just like it is with any other proprietary protocols.

It's "open" because it's documented and the implementation is FLOSS, but it's also "proprietary" because effectively, Mozilla is in full and ultimate control of this stuff.

They are on day one, sure, but if the file format is documented and clear then there's no reason why other managers couldn't interoperate. It's not as good as using an existing standard, but I'm not sure there is _an_ existing standard right now.

> I'm not sure there is _an_ existing standard right now

I think there is none, except for the OS-provided APIs (but those have complications of their own, e.g. Chrome had dropped Apple Keychain support for a reason).

> there's no reason why other managers couldn't interoperate

Why would they? I don't think anyone was invited to this party. And I find it highly unlikely someone will bother to interoperate beyond implementing an importer tool, because it's likely that no one wants to spend resources on alternative implementations just to be in dependent always-catching-up position.

Seriously, I absolutely don't see how this could become a standard. I've called it proprietary not to badmouth it, but because it is Mozilla's own, unique stuff and is very much likely to remain so.

I believe if someone wants to devise a standard for something, they call for everyone having their in-house implementations, asking if they want to interoperate. Many won't bother, but some may like the idea. Then, a specification is written, and conforming implementations follow.

That isn't what proprietary means, though. Every criticism you level at this file format _can also be levelled at the others_. There's no way around that at this stage. The only way mozilla could not have caused that problem is to not have built anything like this.

> can also be levelled at the others

Password manager storage/exchange formats? Sure, there are no standards at this point. Arbitrary formats or protocols? Certainly not. Similar cannot be said about e.g. HTML/CSS or WebDAV or OpenPGP - even though there are enough incompatibilities, deviations and proprietary extensions.

> The only way mozilla could not have caused that problem is to not have built anything like this.

Of course. I don't think anyone needs yet another password manager, for there are a lot of options already (although many lacking one thing or another, but it's not like Lockbox is going to be the perfect one).

Mozilla are in touch with standard bodies, like W3C. They are participating in development various authentication protocols like FIDO2. Surely they can raise a call for other password management software vendors to devise a common API. Some would not want one (besides importing into their product), some would enjoy a capability to concentrate on some parts of the product but leave others to compatible third-party implementations (e.g. backend/frontend separation).

It's not a bad thing, of course, to build another password manager. I just don't see anything good about this, either.

While a lot of Mozilla's work is great, this seems to be the tendency of every "Test Pilot" project I've seen; NiH and always a reimplementation of ideas there are plenty of alternatives for already, without much consideration for learning from/interop with those alternatives. It's a bit odd: it all seems quite separate and "distant" from the core work I expect from Mozilla.

I think someone in their management has/had a vision of Mozilla as an ecosystem brand, just like Google or Apple. They must've felt big enough to pull it, providing users with all things Firefox (think of Firefox Account).

They hadn't succeeded and had cancelled Firefox OS, but at least the inertia is still there, if not the continued effort to push in that direction.

Just wait until Google releases a more robust one for Chrome. All these other ones will be left in the dust...not looking forward to that day.

Seriously, if you put Mozilla in the same box as Google, Microsoft and Apple, then you are ignoring company culture completely.

Yes, I want a big privacy oriented, non profit organization with strong engineering practices to handle my passwords. This is not Google, Microsoft or Apple.

I only wish Mozilla wasn't American due to the insane laws about "national security".

I'd love to be wrong about this, but I don't see them as privacy oriented - only marketed as such.

Mozilla made it harder for me to handle my passwords. In their effort to not lose market share and to market themselves as ecosystem rather than a browser vendor, they did horrible things to their password storage. Sync1.1 was tolerable. Accounts+Sync1.5 is an abomination. It's bloated beyond reason, full of weird protocols and formats mixed in odd ways. I'm not even remotely a strong engineer but I can't call what Mozilla made there "good engineering".

And I spent some time writing my own implementation of Accounts and Sync, so I believe I can assure myself my opinion is not completely baseless but relies on some first-hand experience (my crappy code is not good engineering - but neither I claim it such)

I am curious how it works, technically speaking.

I already have this capability with password-store (pass), that works for Firefox, Chrome and Safari on destop and mobile.

pass - https://www.passwordstore.org (core program)

passff - https://github.com/jvenant/passff (firefox desktop)

passforios - https://mssun.github.io/passforios (ios w/firefox mobile)

qtpass - http://qtpass.org (osx, linux, windows)

OpenKeychain and Password-store (paired with a yubikey) is the entire reason I use Android over iOS. I really wish there was hardware GPG key solution for the iphone.

Did you see it's missing a maintainer?

I agree, using gpg on yubikey for password encryption is ideal. My only problem with it is that nobody makes money, so who is maintaining it?

Capitalism continues to wow the masses

Don't get me wrong I would pay... But there is no attempt to make money from this.

Cause it works great and even supports TOTP and extra data, aside from passwords.

I've been using pass with a yubikey for the past year and a half and have been very happy with it. The ability to call out to the pass binary in personal scripts is a really handy feature that I didn't realize would be so useful until I started using it.

Same and it is fantastic!

I've been working on this distributed offline-first datastore that uses the Git protocol as the network layer. I'm calling it GitDB (but the Git trademark is getting more strictly enforced these days so that'll need to change).

The idea is that we should be able to build tools where the user can understand and manage where data is stored while at the same time keeping many of the conveniences of modern apps, like cross-device sync.

As a user, you can decide if you trust Github, Gitlab, Bitbucket, etc. and pay them to host your data.

The first tool I wanted to build with GitDB was a password manager but seeing this post made me wonder if there would be enough people who wanted this level of control over data, does this sound like something you'd be into?

This work is all super early, but would love to gauge the interest from others.

If someone wants to help build this thing: https://github.com/the-gitdb-cooperative/gitdb

Pass (https://www.passwordstore.org/) uses git as a password database in a similar way.

AFAIK pass won't handle conflicts for you (please correct me if I'm wrong!).

This isn't a big problem for a password manager since conflicting changes are very uncommon, but for other apps this starts to get more important.

It just does what git does. Since every site has its own file containing just a password, merging conflicts isn't a common issue.

I hope it only uses normal git stuff, so that I can selfhost it too on my laptop or on my computer at home as I do with my private git repos?

Yep, just pure git, it's nothing fancy on that front.

If this is any good I'll be considering it as a replacemnt for Keepass.

A bit off topic, but while looking at this I noticed another expirement - Firefox Side View. It looks like it lets you have two open tabs side-by-side in one browser window. This is exactly why I used the Tile Tabs[0] extension and had to switch to Tile Tabs WE[1] with the Quantum update. I'm happy to see this coming back without the WE workarounds.

[0]: https://addons.mozilla.org/en-US/firefox/addon/tile-tabs/

[1]: https://addons.mozilla.org/en-US/firefox/addon/tile-tabs-we/

The reason I haven't switched to Keepass is its very decentralized nature - not in terms of how it stores data, but in terms of it being a format not a unified set of tools.

Maybe I'm misunderstanding it, but it feels to me like I can get Keepass (v2.x or v1.x) for Windows from a somewhat-official source. I can also run that v2.x on Linux or OSX via Mono (via the packages on the download page?), or I can use any of 4 unofficial OSX ports or 2 unofficial Linux ports, plus any of several unofficial browser ports, plus an unofficial webserver based port, plus 3 unofficial Android ports or a bunch of unofficial iOS ports. It's not clear to me how many (if any) of these are actual "ports" of the software not "reimplementations of the file format," nor is it clear to me whether any or all of them are audited (or who's doing that if they are).

Basically, massive fragmentation and independently developed clients in the software that I'd use to store all my passwords behind a strong master key creeps me the f out. I don't have the time, math or detailed language knowledge to personally audit a bunch of cryptography implementations in a bunch of different languages and I know it, and I'm not sure I'd pick up any obfuscated transmission or concealment of security/decryption information, but I also don't feel like I have a trustworthy source that I know is doing that auditing.

I use Android, Linux (at home), and Mac (at work). I switched from KeePass because the UI was really bad, it seemed dead, and I really didn't want to move to KeePass 2 (with Mono on Linux). I switched to enpass, and it's been great. It has native Linux/Mac/Windows apps, a solid Android app (with fingerprint support), and there's no subscription. It's perfect for my needs.

The newest kid on the block is KeePassXC https://keepassxc.org

The browser extension leaves a lot to be desired though. I feel that there are a lot of good standalone password managers, but the ones with good browser extensions are far fewer. I'm using bitwarden right now, which so far seems to be the best of the open source ones in terms of usability.

Hm, enpass seems to be closed source which makes it unusable for me to store all my passwords basically because of the same as someone wrote in their forum:

"The fact that Enpass isn't submitting all my passwords to enpass.io right now doesn't mean anything. I'm currently using iptables to restrict Enpass from doing so, but I don't know yet how to archive the same thing on my unrooted Android."

That's the problem I have with all of the commercial password managers: I simply don't trust them.

I find it incredibly telling that every big password manager has a mandatory, binding arbitration clause in their user agreements. This tells me that I am supposed to take their word on everything yet I have zero recourse to a neutral third party if the password manager company leaks (or intentionally hands over) all of my passwords.

That's not reasonable.

Unfortunately, I have a similar issue with things like Keepass - perhaps the core project has enough eyes on it, but how about all those "Contributed/Unofficial KeePass Ports"?

Totally reasonable. I figure the people who write the unofficial ports I use have a personal reputation to protect. It bothers me a lot that the "professional" password management people disclaim all of their liability and just expect me to hope that it works the way they want.

I kind of figure almost the opposite - those commercial entities have both the resources (hopefully) for subject matter experts and auditing (also hopefully) and a strong financial interest in not having a disclosed breach (and almost all significant breaches are likely to be disclosed/discovered at some point). On the other side a small development team of individuals seem (to me) less likely to have the resources and more ability to simply walk away in case of a breach.

Because they don't offer to save your passwords the breach can always just be if someone attacks your personal computer, which is so much less likely than that someone tries to attack a company which hosts thousands or even millions password databases.

In the open source world you have at least the possibility that someone who you trust looks at the code, with the closed source you don't.

Ot: Shouldn't your window manager handle this ? Consider using i3wm if it does not. Does this work seamless with other web extensions ? As a webextension developer i do not know how those tabs will be handled. I do not see any benefits using this.

Here's some more in-depth information on the architecture of Lockbox: https://lockbox.firefox.com/architecture/

I am a fan of the quality of dev the Firefox team has, and am sure they have thought this through very deeply. For trust and security, it would be helpful if that were reflected in the specs as well as the final product.

I was the architect for a solution solving a similar problem some years ago, and then, as apparently now, the key derivation scheme appears to be a bit of a shell game. Was just reading this and trying to get a picture of how someone could reason about trusting it. This doc specifies four symmetric keys, where two are used for encryption, and two are used as salts.

The salts are derivations, which are hashes from data elements

So simply, we have:

FxA credentials: a string or blob to be determined.

f: some function tbd

k_pre: a bootstrapping scheme initialization key.

k_enc: keystore key.

k_salt: a user-bound diversification component

k_item: a key to encrypt an item within the encrypted container, or "lockbox"

Some definitions:

k_pre :=(f(FxA))

k_enc := (f(k_pre))

k_salt := KDF(k_pre, userid, infostring, length)

item := KDF(k_salt, k_enc)

Question is, what is FxA? Best thing could be is an HSM key with a user-bound diversification component, with some kind of secure provisioning protocol to get it into the device, but from what I can tell from the docs, there are still some exercises for the reader.

What wasn't clear on first reading from the architecture was the protocol they use between where the lockbox is stored, and where its components are used. When I did this, we used a variation of OCRA to prove possession of correct keys and their versions and release verifications for "items," (attributes).

The next useful documentation step would describe a sequence like:

A -> B: init msg

B -> A: challenge

A -> B: (userid, key version, HMAC(k_pre, challenge))

B -> B: derives k_pre(userid)+ HMAC, validates

B -> A: challenge'

A -> B: etc...

Not to be a pedant about this stuff, but to be able to reason about the things we can trust it for, there are some things we can't be handwavy about.

If I'm already using Firefox on Mac, Windows & iPhone, what advantage does this bring over just opening the Firefox app on my iPhone and looking in Settings > Saved logins? Seems to me to be exactly the same, am I missing anything?

It's faster. It syncs. It's safer than firefox passwords manager. It unlocks integrates better with the OS (unlock with fingerprints or face). You can use it for something else than websites.

However, it's still nowhere as convenient as lastpass.

But it's a good first step. I wish them luck.

The existing app already syncs, though. "Faster" we'll see. Integration is probably the main point.

Ease of use:

1. Don't have to open a browser and slog you way through a settings menu.

2. Native app for iPhone and Android will allow you to auto fill these passwords in apps.

3. Easier management of passwords because you now have a UI with the sole purpose of managing passwords.

Also, this doesn't lock you into using Firefox, you can switch to whatever browser you want and still use this for managing passwords.

If they release an Android version and improve the browser UX this could be a good alternative to 1Password or LastPass.

I would absolutely love to have this on Android and available worldwide.

I'm betting it's in the works already.

Edit: Yes, can confirm. It is in the works. [0]

[0] https://goo.gl/forms/ZwLIfHSGLrYcM6k83 (link from the announcement article)

Has anyone done a thoughtful comparison of PW managers?

I moved on from keepass because it was a huge hassle to use, but LastPass and 1password both have some detractors as well.

I paid a one time license fee of 1Password, then I use it offline on laptop and iPhone. I sync them through wifi regularly.

This offline use option is not very disclosed on the website but it’s possible and in my opinion it’s more safe.

I’ve tried open source password apps but the problem it’s they are all from independent developers. These developers can’t afford security reviews and I can’t tell if the version on the App Store is the same of the version on GitHub. If there’s a vulnerability and passwords leak, a company can be legally responsible, it’s not the same with independent developers.

And it’s not practical to install an app and its updates from source on iPhone. So I went with the closed source 1Password because it’s a big company and everybody is looking at them.

I'm using 1password the same way as you are. Their linux support is poor though.

1Password is the best and I tried them all.

A little pricey, but I've got important data in it and I use it every day, so at the moment I consider it to be worth the ~36 EUR per year. Previously a standalone license user, I've finally switched to their subscription model. Some people are afraid of storing that encrypted data on their servers, however I don't see the threat model as being any different than synchronizing with Dropbox, which I was doing anyway, plus it makes it easier for me to have a digital last will for my family.

Keepass' copy&paste/autotype always felt like a hassle to me and also a bit insecure. When I was looking for alternatives for Keepass 2 I discovered the Kee [1] plugin for Firefox which communicates with Keepass via the RPC plugin. It's great and made me stay with Keepass. Login fields are automatically filled reliably without any issues. Registering accounts is easier too: just choose a username, let Kee generate a password, submit the form and then click the button to save the entry - all without having to use the Keepass UI at all.

[1] https://addons.mozilla.org/de/firefox/addon/keefox/

I have in the past, but not written it down. My criterion was:

- FOSS (totally indispensable)

- Offline (totally indispensable, data you put on others' servers is not yours anymore)

- Can be used from the CLI as well as some interface

- Can be synced to Android

With this, you have 2 options: pass, or keepass. The latter is a bit confusing, w/ many apps around one format and it's hard to know which one to use. Also the file format is proprietary, which means it's harder to use from scripts.

pass on the other hand uses the filesystem, gpg and git, which are tools I always have around and know how to use. It's totally FOSS and totally local (Keepass is like this too), it's version controlled by default, can use it on android w/ Password Manager and OpenPGP apps (available from both the play store as well as FDroid), and it's easy to script (I've written my own Emacs fronted in no time), and while there are many third party frontend apps, there is one program that's blessed by the community as the default one, which is the pass(1) cli.

One criticism on pass is that it leaks metadata because the file names usually contain the website domains. I think that's a non issue because usernames and websites are already known by many other parties (the website itself, and millions of people if it's sth like a social network), and we should not rely on hiding public information for security. Use long passwords and 2FA where available. But encrypting your hard drive would be more secure in the first place anyways.

edit: formatting

I specifically use keepassx and v2 format keepass file db, separately, because it is not integrated with any browser via extension or plugin. Keeping things compartmentalized reduces risk in my opinion.

And unless I copy the locally stored .kdbx file somewhere manually, it has zero interaction with any network, cloud based service, or third party beyond my control.

I was tired of browser plugins that just didn't always work quite right.

Keepass, on whatever platform using whatever client, just uses the clipboard. 100% chance of working, although not safe against certain types of spyware.

It's not all clipboard based - Keepass has an RPC plugin that can be used with browser extensions for Firefox and Chrome. I also use Keepass2android for (duh) Android, and while you can use copy/paste it also has a custom keyboard you can use instead.

True, there are other options, but the fact that it works really well as a simple list of my passwords is what I like most about it.

Between Chrome's cross-platform autofill, Firefox's autofill, and browser plugins, I have too many things telling me what my password should be. s

> Keepass, on whatever platform using whatever client, just uses the clipboard. 100% chance of working, although not safe against certain types of spyware

On Android the preferred way of using Keepass is with custom keyboard, which protects against clipboard sniffing.

> Has anyone done a thoughtful comparison of PW managers?

I think a valuable comparison would not be of features but of the security, and therefore a person comparing them would need real security expertise. I'd worry about bad information from non-experts. In the past, at least some security experts on HN have recommended 1Password.

All these people storing all their secrets in one place creates an exceptionally valuable target that I expect, IMHO, will attract well-resourced attacks. Find a way to crack Lastpass, and imagine what you have - it's the ultimate breach (and if you are smart, nobody will know).

To be a net gain in security, a password manager needs very effective security for itself. If the user wants something to ease the burden of managing all those exposed passwords, then perhaps features are the issue.

Wirecutter has done a comparison of them.


And they picked the one that has had several high-profile security breaches... Not very credible.

Which ones have fewer breaches? Is there a comparison writeup somewhere?

Lots of grimness: https://www.theregister.co.uk/2017/02/28/flaws_in_password_m...

This is interesting, and I'm looking forward to seeing where it goes.

However, it's very unlikely to replace Bitwarden for me.

There is a surprising lack of unit tests in Bitwarden, which is mostly maintained by one person. If Mozilla can apply its rigorous engineering practices to maintaining an open source password manager with all the features I use, I will switch from my current system.

I'll admit that some of the Bitwarden clients are... less reliable than I would like.

"Test Pilot", "Experiment" are not words I want to see when it comes to my login credentials.

Everything starts out so, so we can wait until it's stable, no?

Then you are not the target audience yet.

Love it. I don't love using LastPass, but I don't want to deal with the rough edges of KeePass either. Looking forward to the Android app. +1 for autofill API.

Rough edges in KeePass?

The need to use a third party plugin to get any form of cloud sync working for one. Minor weirdness with it scrolling through your secret share structure on the left instead of up and down your passwords if you have accidentally clicked over (a feature that acts more like a bug). The lack of ability (or at least any documentation) on how to use something like Google Authenticator as MFA for the database.

The external sync is a feature for me, not a bug. I can use whatever tool I want to sync between my devices (I use Syncthing) and do not need to trust some company with storing my stuff on their servers and not fiddling with them.

It's UI is outright ugly.

Can't believe they didn't call it Lockfox.

Firebox Lockfox? Firelock Boxfox? Lockfire Foxbox? Ugh, we tried them all, I swear..

Just plain old Lockfox. However, I understand you probably have some branding/marketing/PR concerns to keep in mind with naming.

Lockfox sounds like something that breaks or works around locks to me, fox being a sneacky tricky animal; not really reassuring.

>> "fox being a sneacky tricky animal"

Foxes are good and pure creatures.

But it has certain connotations in many cultures, which is not positive. I too like them and know they aren't a part of our value system, but naming a security product that is meant to protect your valuable stuff "fox" is like calling a bank Robbers&co.

That was humor. I'm aware of the centuries of anti-fox propaganda.

From the link, it claims that this "gives access to all the logins you've saved in Firefox", but I thought it was common knowledge that in-browser password storage is insecure? [0,1]

If so, then this doesn't really promote much confidence in a product that appears to be a password manager. If they've addressed this issue, then that should probably be explicitly stated, although I understand the difficulties of that from a marketing perspective.

Maybe the reference to 256-bit encryption is a nod to this, with the expectation that those unfamiliar with the problems wouldn't be familiar with the differences between plain-text and encrypted storage?

Regardless, I think it's pretty promising that a browser is addressing this problem head-on, rather than leaving it to third-party companies to solve in a cross-platform way.

[0]: https://nakedsecurity.sophos.com/2018/03/20/nine-years-on-fi... (If you don't use a master password, which isn't required, I believe?)

[1]: https://www.wired.com/2016/08/browser-password-manager-proba...

> in-browser password storage is insecure

> (If you don't use a master password, which isn't required, I believe?)

When using a cloud-synced password vault that lands on the servers of a third party (this includes Firefox, Google, 1Password, Lastpass, etc.) you must always assume that the file itself is compromised; the only thing between an attacker and your passwords is the encryption by your master key.

I seriously doubt that Firefox Lockbox will allow you to cloud-sync your password file without setting a master password. *

Note: One of the first things malware authors typically go for is the password vault stored in browsers, but this is only because it is commonly used without any master key set.

* It might depend on some key derived from your account password, if you haven't observed the requirement of a master key. Not sure.

> I seriously doubt that Firefox Lockbox will allow you to cloud-sync your password file without setting a master password.

The current Firefox Accounts protocol simply encrypts a master key with a key derived from the account password. That's not terrible, although it does mean that account passwords must be cryptographically strong. However, Firefox Accounts can be logged into from a webpage which executes JavaScript served dynamically, which means that Mozilla, a Mozilla employee or any government or organisation which can compel Mozilla or Mozilla employees can serve targeted JavaScript to you to steal your master password, and then silently read your passwords. As such, Firefox accounts cannot be trusted with high-security passwords.

(Yes, you have to trust Mozilla to run Firefox at all, but it's significantly easier to hide a single download of a compromised JavaScript file than it is to hide a compromised Firefox binary served to the world)

If you are a likely target for a government entity with subpoena power you have much bigger problems than your Firefox Accounts password. The problematical scenario is that Mozilla is remote compromised by some bug or poor opsec and criminal entities will serve compromised JS. Since this has literally happened to basically every kind of organization out there, it is virtually certain to happen to Mozilla.

The problem is that Mozilla is aware about the issue for years, yet is not doing anything about it, even though the auth protocol is stable and documented. Okay, I get it that they may not want to rewrite already working parts of the browser - but even in this new Lockbox project they're using a WebView to log in to FxA.

<fud>Maybe they're already breached by highest-profile actors like NSA?</fud>

On problem with password managers (that are using web authentication to create/manage an account for backing up the password manager in the cloud) is that the authentication password can be leaked during the authentication process. For example, the storage provider for password manager backup can simply read the password from the authentication web page since this web page is hosted at the provider. This is problematic if the authentication password is also used to encrypt the password manager, i.e. the provider could decrypt the password manager with the authentication password. You would actually need two passwords; one for authentication and one for encryption. Unfortunately, you usually don't even have the option to choose two passwords.

To solve this problem I'm working on FejoaAuth (https://fejoa.org/fejoapage/auth.html). FejoaAuth uses an authentication protocol that does not leak the user password to the provider who is going to store the password manager. This protocol is run in a trusted browser plugin in order to ensure the correct execution of the protocol. Thus you can use a single password for authentication and password manager encryption.

So can someone expand on this a little? What are the differences between this and something like LastPass (other than this isn't an add-on). Does it provide app autofill? Does it prevent the same plain text decoding that browser password managers typically have? Is this useful? I'm legit asking because I don't know and would appreciate a security person chiming in.

The video shows the password being copied (to a clipboard), so I'm guessing it doesn't do autofill. Does iOS support autofill apps?

lastpass on ios autofills if you select it from the safari, uh, box-with-up-arrow icon from the navigation bar

Op said in apps.

This is seriously great! If the eventual Android app uses the Autofill API then it would be a good replacement for LastPass or Bitwarden.

Nice, will check it out! FF is already my default browser. One question though, is there a good way to import from other exported sources such as LastPass or KeepassXC?

Does this have safari integration?

Will it support iOS 12 auto fill?

Most importantly, how likely is this gonna disappear after a year or two like so many other Mozilla side projects?

Most likely. The iOS guys that work on Mozilla apps are pretty tech savvy and use latest Apple technology.

Yes, us guys and gals working on the app are planning on the iOS 12 autofill API integration: https://github.com/mozilla-lockbox/lockbox-ios/issues/445

Yes, thank you! Moving too fast today. :)

Keep up the good work! Not surprised you are already considering it.

I appreciate the vote of confidence but I was hoping someone from the team could chime in or someone who took the time to try it out. Based on other comments in this thread it looks like it may just rely heavily on copy/paste.

It’s not a vote of confidence, it’s my professional opinion as an iOS developer.

If push comes to shove, since all Mozilla iOS projects are open source, anyone can add this functionality.

I wonder if it also works with the self hosted firefox sync server or if they forgot to add a UI to change the URL to the sync server.

Are Firefox passwords encrypted on the client? I currently use (any pay for) Bitwarden and I like that the code is open and my data is encrypted on the client and only synced with the server. I'd like a similar service from Mozilla, but don't know how the encryption is handled.

as others have said, it's encrypted if you enable the "master password" option; however, the ux of the master password is miserable:

* the prompt for entering your master password is a simple dialog, with "ok" and "cancel" buttons. a website could probably trigger an identical prompt with javascript to phish your master password.

* the prompt pops up once when you first start the browser (about 15-30 seconds after everything is loaded) and then (if you dismiss it with "cancel") again each time you visit a site for which you have a saved password. there's no way to trigger the unlock prompt on-demand.

* the master password doesn't have a timeout. once you've unlocked the keychain, it remains unlocked until you restart the browser.

don't bother. stick with whatever third-party extension you're using.

If you have master password set in the browser then the password db is encrypted locally. I remember there being some noise about it not being very secure encryption, so better check the details if that is critical for you. As for the Firefox Accounts/Sync stuff, afaik MozCo servers see only encrypted content.

https://medium.com/mozilla-tech/how-firefox-sync-keeps-your-... might provide more insight

One of the ideas I had once was to build a client for Firefox Sync, either as a plugin for Keepass or as a native standalone application (that could possibly sync with Keepass database). While this does not exactly match such use, it kinda still is a step towards that direction.

I am considering this but worry that mozilla has a history of shutting down initiatives and products.

A history of shutting down site-identity related products, no less. [1] The fact that it's not on Android as of day one looks pretty bad too; the sort of developers who think iOS obviously comes first are (in my experience) likely to be chasing hype and their apps are dead in a year (or at least still not on Android). I don't know if that's the case here, but I have no interest in using this until it's been adopted by Mozilla as more than an experiment and has several years of strong support.

[1] https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Per...

(I admit I'm biased here but I'm still bitter about them nixing Persona.)

I was under the impression that the password manager for Firefox had some security issues.

Yes, that's why it's not using it. It's only importing from it.

Firefox password manager is also getting a revamping, which probably is a sister project to this one.

Thanks for the thoughtful reply

I wonder if the passwords are encrypted from end-to-end.

I am not very confortable having my passwords in plaintext, even on Mozilla servers.

Your logins are encrypted end-to-end, with a key that Mozilla's server don't have.

You can find more about how sign-in and key management works in https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc...

I haven't looked in to it, as I'm not an ios user, but Mozilla would be very stupid if this isn't end to end encrypted. And as far as I know Mozilla typically isn't stupid.

`will sync to the app using 256-bit encryption` is not very reassuring. It seems to be regular SSL without a master key.

It's easy if Firefox directly activates Sync instead of sending a Confirmation link to registered email a/c

For me, 1Password has taken care of this space for years, so I'm curious how this will compare.

It could be shipped by default with Firefox, facilitating user adoption. Also, free.

Is this a Firefox password manager or a general password manager with integration with Firefox? Should I expect to be able to replace 1Password with it for instance. If I can't then I have no motivation to have two password managers.

Unrelated, does this page implement it's own custom scrolling? I get some weird rendering bugs when scrolling too, very stuttery.

It's a way to access your data stored in Firefox's internal password manager.

Does this have any advantages over an out-of-band system like KeePass/2/X/CX?

Sync, integration, simpler UI, portability and better ergonomics.

I use both lastpass and keepass, but keepass is really disliked by the non geeks around me.

Browser integration in Android/iOS?

Why not integrate it with the mobile browser like Chrome does on Android?

Am I missing something?

Firefox on iOS provides an integrated experience for logins and filling those logins into browser forms automatically.

The team is currently working on autofill from Lockbox into other apps: https://github.com/mozilla-lockbox/lockbox-ios/issues/486. This will only be available in iOS12 when that ships.

Are there other kinds of integration you see as valuable?

I'd like they go with TypeScript rather than just pure JavaScript.

The iOS app seems to be region-locked to U.S. only App Store.

Only for now. This is just the beginning of an experimental product and we're hoping to bring it far and wide later.

Other than "every", what language or regions would you want/expect/need first?

Honestly, the region shouldn't matter. If you want you could add a little notice that it's English-only for now, but there's absolutely no reason to limit this to a particular country. It's a totally free service and it doesn't involve complicated region-specific licensing agreements, so where someone lives quite simply does not matter.

All English speaking countries would be a good start for (almost?) zero effort on Mozilla's part.

I hope you are aware of the fact that language and geography most of the time don't match because one person is capable to speak/read multiple languages and that English is understood by people outside of the USA?

Is the firefox lockbox for hot stocks?

A chrome extension would be great!

We hear ya and we're thinking about it. But, it would be a while before we started to build one. An Android app is up next up on our list...

Insert Al Gore joke here

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact