131–140 of 156 posts
This is interesting, and I'm looking forward to seeing where it goes. However, it's very unlikely to replace Bitwarden for me.
Earlier quoted context omitted.
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 w…
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 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.
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.
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 prop…
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.
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.
"Test Pilot", "Experiment" are not words I want to see when it comes to my login credentials.
Earlier quoted context omitted.
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.
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.
- 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
Earlier quoted context omitted.
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
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 "encr…
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…
Earlier quoted context omitted.
>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.