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.
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.
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.
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.
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 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.
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.
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.
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.
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.
> (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>
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?
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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?
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.
155 comments
[ 2.9 ms ] story [ 193 ms ] threadA 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.
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>
Firefox password manager is also getting a revamping, which probably is a sister project to this one.
Other than "every", what language or regions would you want/expect/need first?
I use both lastpass and keepass, but keepass is really disliked by the non geeks around me.
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.
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)
However, it's very unlikely to replace Bitwarden for me.
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?
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.
https://thewirecutter.com/reviews/best-password-managers/
Lots of grimness: https://www.theregister.co.uk/2017/02/28/flaws_in_password_m...
[1] https://addons.mozilla.org/de/firefox/addon/keefox/
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
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 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.
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.
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) 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.