Firefox Lockbox
testpilot.firefox.com
testpilot.firefox.com
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.
This is LastPass's page:
https://lastpass.com/support.php?cmd=showfaq&id=1096
But that too you won't find when you use the app/extension normally.
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.
It's probably way to late to make any difference here, but I still wish mozilla could push the boundaries here.
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.
It would be fantastic to have a 'more details' page, where the nitty-gritty is detailed for those who care.
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.
- 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.
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.
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.
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.
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".
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 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)
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?
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
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.
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 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."
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.
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.
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 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.
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.
However, it's still nowhere as convenient as lastpass.
But it's a good first step. I wish them luck.
Edit: Yes, can confirm. It is in the works. [0]
[0] https://goo.gl/forms/ZwLIfHSGLrYcM6k83 (link from the announcement article)
I moved on from keepass because it was a huge hassle to use, but LastPass and 1password both have some detractors as well.
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.
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.
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
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.
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.
Lots of grimness: https://www.theregister.co.uk/2017/02/28/flaws_in_password_m...
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.
- 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
However, it's very unlikely to replace Bitwarden for me.
Foxes are good and pure creatures.
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...
> (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.
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)
<fud>Maybe they're already breached by highest-profile actors like NSA?</fud>
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.
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?
If push comes to shove, since all Mozilla iOS projects are open source, anyone can add this functionality.
https://blog.mozilla.org/services/2014/04/30/firefox-syncs-n...
https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc...
https://medium.com/mozilla-tech/how-firefox-sync-keeps-your-... might provide more insight
* 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.
[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.)
Firefox password manager is also getting a revamping, which probably is a sister project to this one.
I am not very confortable having my passwords in plaintext, even on Mozilla servers.
You can find more about how sign-in and key management works in https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc...
Unrelated, does this page implement it's own custom scrolling? I get some weird rendering bugs when scrolling too, very stuttery.
I use both lastpass and keepass, but keepass is really disliked by the non geeks around me.
Am I missing something?
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?
Other than "every", what language or regions would you want/expect/need first?