I knew that LogMeIn had acquired LastPass, but I didn't know that private equity had gobbled up LogMeIn (which used to be publicly traded on the stock market).

Apparently the private equity deal was only finalized in August of last year, see:

[1] https://www.nasdaq.com/press-release/francisco-partners-and-...

The cost of storage is marginal, 1 subscribing user subsidizes 100-1000 free users. The encryption computation is offloaded to the client as well. That's why this service is a profitable recipe for freemium. I'm sorry you're sorry about the parent commenter's experience.

> You are talking about a _free_ service

The irony of claiming this is a free service when the service uses 7 trackers. The free service is a product!

There are ways to monetize a free service further and some are better than others.

Trello is currently evolving into a full-fledged project management tool and they fuel growth by adding new features to business class only. While that's not leaving the best taste either, I can understand.

When they tried to limit Trello Gold further, we retaliated so hard so, they relaxed their policies a bit.

I don't need their new features since it's not well organized for individuals but, they neither change the price of Trello Gold, nor remove features from it. It's a good compromise.

If customers had known this would happen when they put their data on LastPass, I think I would agree with you. In this case, LastPass is using a classic bait and switch tactic on their customers, which seems within their rights but is definitely not earning trust or loyalty from anybody.

Look, I get where you're coming from, but LastPass's behavior is just not clever at all. Frankly, if I had to think of a better way to antagonize my users with 100% certainty, I couldn't have done a better job myself (short of disabling free accounts overnight).

So when you're building a brand you have to ask, how much is the bad press and the millions of disappointed users worth to you? You have to understand, users you're losing this way are never coming back because you have nothing to offer them anymore. And they'll tell their friends, family, colleagues, bosses and just like that you lose a huge userbase.

OTOH, if you treat your free users with respect, chances are they'll recommend you left and right and a percentage of these recommendations is bound to convert to paying customers. Of course if you're greedy and want to milk your customers for all they're worth and you don't really care about the long-term success of your product or your brand, then by all means, go for it.

Another thought experiment: Imagine I gave you a generous gift for your birthday, like a new gaming laptop. You'd be using it for a few months, you'd finally throw out your old desktop PC and create your whole digital life around this laptop, install all your software, configure all your shortcuts etc. Then one morning I'd just show up and say, either you're paying my $$ every month from now until you die or I'll make it so that the left mouse button/half the RAM/the right screen half don't work anymore. You'd be just the tiniest bit pissed about that, wouldn't you? Sure, I'd claim that there was a file in C:\Windows\system32\drivers\etc\giftconditions-eula.txt that said I could do that anytime, too bad you didn't read it. But because while it looked like I was being generous, my goal was to trap you and then force you into a situation where it's ostensibly easier to just give me some money every month than to switch your whole life back to another system and build everything again from scratch. Additionally, even if you agreed to pay me, I'd now hide a few rootkits and trackers on the device, cause what are you gonna do? Sure, I might say, feel free to copy all your files to a USB stick and use them elsewhere (GDPR) but come on...

Yeah okay it's not the same. But can we agree that LastPass's behavior is a great example of how to make people angry at you?

> this comment is entitled

One who set an expectation ought not be shocked when one's users have that expectation.

I don't think they are evil, but I do think they handled this transition poorly and with messaging that clearly didn't win their users over to their side.

Also, tracking is bad. I wouldn't do business with them on that basis.

Which is also a requirement under European GDPR laws.

Yep, exactly. I have no problem with gentle reminders to check out pro features. Or maybe a recommendation engine ("Refer 10 of your friends to us and we'll give it to you for free"). Or making it clear to new users that the service tiers are now different and grandfathering-in the legacy free tier (like Gsuite used to do).

There's any of a dozen possibilities that allows you to monetize your service without antagonizing long-time users (if you believe LastPass really had an unsustainable ratio of free to paying customers, which I actually don't, I think they're just trying to milk it).

Adding spyware/trackers to a privacy-centric app and forcing customers to "pay up or leave" at a moment's notice, nah, there is no good excuse for that.

Also the LastPass desktop client was beyond slow.

Not laggy rather than waiting time in the multiple seconds range.

(Some will probably think this was because of encryption but ok the same machine the Girefox extension was snappy.)

Of course facts aren't FUD. I'm responding to a lot of comments here which assume this is a bad thing, which I think is obviously why it's being upvoted as well.

And I'm not sure you understand the term FUD. You're saying my comment spreads fear and uncertainty? It's literally the opposite, I'm saying this particular thing isn't something to worry about.

Mobile apps aren't like webpages where most actions generate backend calls whose logs can be analyzed as an alternative. If 1password isn't using 3rd-party analytics, they probably rolled their own. No big difference. In any case, my point remains true -- client-side analytics is standard for essentially any commercial app, in order to improve the UX. There are exceptions of course, like for any rule, but it doesn't change the fact it's still standard.

Been hearing good things about bitwarden, just switched in about 2 minutes. As a password manager, Lastpass hasn't really improved with the times, infact it's been getting buggier and buggier with Chrome as times goes on.

It's bee a couple years but the web browser plugins for BitWarden were unreliable. Our power users made it work but our average office user complained non-stop and moved back to using notepad. Maybe BitWarden has improved since then but it was too immature to rollout to the average office user.

How does Bitwarden.rs[0] (RUST IMPLEMENTATION) relate to the open source Bitwarden and its hosted cloud service?

[0] https://github.com/dani-garcia/bitwarden_rs

I also switched from LastPass. I find the Firefox Extension and Android experiences in Bitwarden much more intuitive. The autofill on Android works far better in my experience too.

Bitwarden also supports self-hosting their service.

I was an (on and off) paying LastPass user until 4 or so years ago, not because I had to, but because I felt like supporting it.

Switched to Bitwarden after Lastpass were bought and started tightening the grip I think (yep, I'm fairly sure they were testing the waters already 4 years ago).

Still pay Bitwarden (why not, the price is trivial for me at this point and they deserve it).

Same, I've been very happy with Lockwise, with only a couple of UI complaints here and there.

However, to be clear, Lockwise also ships 2 trackers[0], although one of those appears to be an in-house telemetry tool[1].

[0] https://reports.exodus-privacy.eu.org/en/reports/mozilla.loc...

[1] https://github.com/mozilla-mobile/android-components/blob/ma...

I wish Lockwise was available on other browsers too. It really is a great app.

I wouldn't recommend it for casual users as there are definitely things that are less polished about the way it works, but for power-users it is great. The SSH key integration is really good.

iOS?

have you actually tried to use their support, it was a single guy, who wasn't helpful, when I asked for a different rep, he copped an attitude.

I still use bitwarden for personal use, but I didn't find the product (2 years ago) to be really enterprise ready. [biggest issue, when you share, you aren't sharing, you transfer your password to a group, this password is then no longer backed up, if you make a personal backup.]

The support issue was we had something go wrong with a group, and a dept. lost the passwords entered, but all the shares still pointed to it, so attempting to use it error'ed out.

How well does it work on iOS?

I did the same, however I wish 1password would keep my extension logged in instead of asking me to type up a convoluted password every time I open the browser.

My MP is more than 40 chars long, but it's not really a chore to type it in considering we are texting much longer strings than that literally all the time.

Many of them support biometric authentication using Android's API.

Also, to enter the master password, all of them use whatever keyboard is installed, some of them send a message to them to work in "incognito mode" for what good that it. That said, for Keepass2Android and KeePassDX, they offer their own keyboard to enter secure credentials on sites you log into once your password manager is unlocked. That allows you to circumvent the system clipboard entirely, which is a major attack surface. Some apps also support the android autofill feature.

What's wrong with typing in 20 characters on a phone keyboard? My password is longer than that and I don't have an issue

Alternatively you can use fingerprint unlock

I use diceware to make a master password that's reasonable to type on a device.

Bitwarden is able to produce diceware style passwords too.

https://theworld.com/~reinhold/diceware.html

1Password allows you to use your fingerprint on Android and I'd assume TouchID or FaceID on iOS as well.

The other question would be, how do you handle this without a password manager?

And is this a known problem of Android, that there are keyboards that can log your keys?

You can use a fingerprint to authenticate on Android.

Keepass2Android can install it's own keyboard.

Be very careful with the keepass Syncthing combo. If you're not monitoring which one had changes, you could get it overwritten when you don't want it to.

Do you know that or are you assuming that?

I find a comment like:

> ...silly SaaS services like LastPass or Bitwarden?

...rather off-putting considering Bitwarden is nothing like LastPass in execution. For starters you don't need to pay for Bitwarden and you can run your own backend for self-host. Some of us use our password managers with others and would like to share things. I'm happy to pay for this feature.

So no, you're not required to leverage Bitwarden as SaaS like LastPass. They're not the same in that respect.

I have no affiliation with Bitwarden other than being a customer who dropped LastPass after the acquisition years ago.

Personally I'd much rather use Bitwarden due to their fully open source nature, and possibility to self host if they ever go down the wrong path.

In addition, there are open source alternatives that have all the features you mentioned (namely the Keepass/Keeweb family).

I just realized my first reply did very little to answer your questions, so I'll take a look at them one by one here:

> Are there any websites or services actually using this?

To my knowledge, there are not many (if any, besides the SQRL forums) working, live implementations out there. I played around with it and got it working on a couple of hobby projects over a weekend and it showed a lot of promise.

> The problem with the solution chosen here is that this requires yet another app for authentication and yet another account for synchronisation of credentials. If this were to be built into browsers, it might replace traditional passwords in time.

This is very true, but I believe SQRL as an open protocol will have long tail legs over time.

> How does SQRL work when it comes to apps? Does the Android app natively support other applications calling it to authenticate? What about authenticating devices that can't run the client application (smart TVs, for example), can they still access the accounts authenticated by SQRL?

At its core, SQRL is essentially a Challenge/Response mechanism. It would be possible for a device connected to a TV present a QR Code and have its session be authenticated by a device using the out of band HTTP request from the SQRL client scanning the QR Code (there are problems with this, like forwarding the QR code via a MITM attack to gain an authenticated session, however, the attacker only has a single logged in session instead of having access to a password that now needs to be changed, and any problems related to this MITM attack would also affect other user credentials like the email and password).

> Right now, SQRL seems to be competing with Webauthn, which has been built into browsers already, but does so through an external daemon running alongside the browser. I'm not optimistic about its chances here, to be honest.

Short term, I agree with this. However, long term I think WebAuthN is going to suffer from other problems which do not affect SQRL (user adoption of 2FA keys and user inconvenience in managing those 2FA items) SQRL provides some really nifty ways to transfer an identity safely to a host of other devices as well as rekeying an identity with the rescue code in the event an identity is compromised. It also doesn't require the management of those devices on any third party site.

The four PDFs present on the SQRL page to a better job explaining than I will here, however I'll summarize a bit:

The SQRL client registers the sqrl:// prefix to pass the login challenge to the SQRL client. The client, after a password or the pin (depending on if the password is present in RAM) is entered, responds to the server using signed credentials which are only valid for the domain being authenticated. That challenge creates a logged in session for the user and redirects back to the website.

There is also a QR code method of logging in, which depends on the user to confirm the domain name of the site being logged into. This is admittedly less secure, however, does provide some handy convenience when on an untrusted system by not requiring a user to give up their password. There are attacks that can be used to gain a session, however, these are thwarted when the on device authentication path is used (which requires some software to be installed on the users device)

All of these points have inaccuracies, and I'll run through them one by one:

> For one, the identity string it generates for a site is static, and is the only thing need to identify/log you in. They never cover that this basically _IS_ a password. If you have a this static string, you have the password for that site.

The identity generated is a public key based on a private key in the identity. You do need one password, the master password for the identity on the device for an initial decryption to make the Challenge Response work.

> Further it sounds like the website operators also need to store these strings as plain text. I don't know how their rekeying method would work other wise.

What the website stores is a public key. Rekeying works via some other cryptographic methods to create new public keys. A server, presented with a previous public key and a new public key will replace the previous key with the new key. The new key can be confirmed as belonging to the previous identity, while not able to be regenerated by the identity without the rescue code. Full disclosure: Didn't really understand the math behind it, but that's the premise of the protocol. Securing that rescue code is extremely important and it should be stored separately from the identity (think at home with you birth certificate in the event your device is stolen while you are somewhere else).

> This means to me that if a websites database is stolen, then a person with that database could impersonate everyone immediately! No need to get a password cracker out at all.

The database only contains public keys of the user for the purpose of authentication. This table could theoretically be published, the compromise of the key does not compromise the identity nor allow a thief to log on (it would obviously not protect other information tied to the user like the email, address, etc. However, its a step in the right direction because it isn't a hash of a password to be rainbow tabled or the like).

> A website operator would need to completely disable all the existing keys, requiring everyone to rekey.

The compromise of all keys in the db would not compromise any identities. If a malicious actor changed identities to their identity, then there would definitely be problem, however, the operator could restore the public keys from backup and keep moving. This is not much different from passwords today, except that the user could no longer trust the password, no trust is lost in the public key.

> They have a global rekey method, but all their single site methods documented are very very manual and only possible if the site accepted you're old key.

This is valid. I'm imagining a perfect world with a correctly implemented spec. We can all work together to make it a reality.

> The global rekey method is also very scary to me. You need to visit a site for the rekey to happen. They state that after a rekey it will send your current and old key over. However how many keys will it send? What happens if I have to they N times because of different site data beaches. Will sites I haven't visited no longer be usable because their key is no longer available?

It would be semi-true that you would lose access in a world where software is the only intervening factor. The reality here is different: The public identity is string in the DB associated with the user. A website operator can have a user come in with their birth certificate and passport or whatever, verify a user, and change their public key in the database. This would be totally out of scope of the spec, not expected behavior, and potentially compromises perfect security, but the reality we live in is imperfect.

Everything, at some level, is going to come down to trust, and anyone with DB access can do anything anywhere anytime.

EDIT: I reread this again and realize what you are talking about is the string of the public key being stored, and potentially providing an avenue for an attacker to replace that string with their own identity in order to gain authorization of that user. I do think that is a risk, however, an attacker with DB access is probably not going to waste time impersonating users: they have access to the DB directly.

This would only be a problem in the instance a users data is encrypted and can only be decrypted by the user. So logging in as the user would grant some special way of seeing their data (though even here, if the server holds all the secrets, this isn't secure).

SQRL has an answer for this, as a private key can be stored with the SQRL identity to allow data to be accessed by the user who can also prove they have access to the identity. This would allow a server to reliably store sensitive information without worrying if the public key of a user got changed to allow a malicious actor to impersonate said user. I can only imagine this being leveraged for medical records or financial transactions, but a way is built into the protocol.

The first document, SQRL explained, does a decent job describing how the system works. Having to download a PDF to read text on a website isn't the greatest of UX experiences.

The talking to seems to happen through a custom sqrl: URI-scheme. That's something that's supported by most platforms I know of; Steam uses the same mechanism to start installing a game you purchased in the browser, if I remember correctly.

Source code for several implementations is linked in the explainer document from the home page: https://www.grc.com/sqrl/SQRL_Explained.pdf

I'm not sure if the Windows implementation is open source, but the algorithm itself is.

To me, it's much more concerning that they do such a bad job of telling me what SQRL does than the fact that the page looks dated. At least it's clean-looking.

But I clicked around for a while and only found some videos that might show me what SQRL does, but I didn't actually feel like watching a video, so I still don't know.

Based on what I read, it sounds like snake oil so far. Too good to be true. I don't remember the phrase, but it suggested it would be my last password solution ever, which just sounds like snakeoil.

Also, it seems like only the Windows implementation is mature. All other implementations are by third parties and are marked as not being complete.

There is a much better explanation here:

https://security.christmas/2019/2

The spec was recently completed and there are multiple efforts to bring it into a more well rounded existence. The work is being done by volunteers, so it may take some time to become a reality across the internet, however, the seeds are all there to make it work and with some dedication from volunteers I think it has a bright future as possibly being the preferred password manager in the future. If you browse the SQRL forums, you can get an idea of where all the different efforts are playing out, but there is no real central repo of all SQRL code. https://sqrl.grc.com/

To clarify: the issue is that autosaving works only some of the time, not that it doesn't exist. From observation, it seemed to be overly keen at one point (prompting excessively) and now is very shy (not prompting even when it really should). At least that's my experience on Firefox. Seems to work better on FF/Mac than FF/Win.

I agree that the Bitwarden cli is awful. You have to log in, and store the token it gives you manually so that it knows you're logged in.

However, I found https://github.com/doy/rbw , and alternative OSS cli written in Rust, and it's exactly what I wanted. (Disclaimer: I liked it so much I wrote a rofi integration for it.)

I've never had a use for a command line password manager so I've got to ask: how does this fit into your workflow? I'm honestly mostly using a password manager in my browser and on my phone; I don't need command line authentication all that often.

I didn't even know LastPass had a CLI, but it seems like it's a rewrite of the algorithm and surrounded toolset in C.

I can understand why the Bitwarden devs didn't want to go through the effort, though. The tiny minority of Linux-users that want a command-line password manager is not exactly worth a lot of development time, so I figured they just put their JS library in a NodeJS application and called it a day.

> Autofill is relatively poor (it fails even on HN!).

Autofill is much more customizable than LastPass afaik. You can both define how (domain)name matching should occur as you can have multiple entries to match.

This means you can have instagram.com (as website) and androidapp://com.instagram.android (as app) which will use the same autofill entry.

If you configure name matching correctly, any site should be able to provide autofill. My HN entry does match with news.ycombinator.com with default matching settings. But matching settings include hostname / domain name / starts with and even regex!

> Also, Lastpass has a convenient timed expiry that doesn't work (well) on Bitwarden (BW will expire the login when the browser is closed).

You can specify BW timeout settings. Even further, you can define if BW should lock the session (only a password is required to unlock) or if a sign-out is required. With a sign-out, you also need to provide your MFA if applicable.

Time outs can happen directly (after autofill), after an amount of time (1/5/15/30 minutes or 1/4 hours) or upon closing the browser.

So tbh, there is plenty to configure Bitwarden to suit your needs.

I have yet to find a site that autofill fails on. Hacker News works perfectly for me and always has.

As for Bitwarden locking (expiring) when the browser is closed, I disable that as my system is secured so locking the vault in the browser is overkill for me.

My only real complaint with Bitwarden is the macOS app lacks TouchID support.

> Autofill is relatively poor (it fails even on HN!).

In what context? I found Autofill poor on Android for FF before I gave it the "draw over other apps" permissions. Otherwise I've only seen it fail on a few sites out of hundreds, mostly with weird login flows.

> Autofill is relatively poor (it fails even on HN!)

HN Autofill works perfectly well for me with Firefox + Bitwarden extension on macOS (I know it also works with other combinations). If it does not seem to work, select a password field. Does it for me.

> it fails even on HN!

Huh, weird, it works fine for me in Firefox.

I feel like these trackers (Firebase Analytics and Visual Studio Crash Reporting) need to be looked at in context of the data they actually send and who they report to. According to the thread

> In the Mobile apps, Firebase Cloud Messaging (often mistaken for a tracker) is used only for push notifications related to sync and performs absolutely no tracking functions. Microsoft Visual Studio App Center is used for crash reporting on a range of mobile devices. In the Web Vault, Stripe and PayPal scripts are used for payment processing only on payment pages.

Compare this to LastPass where it was feeding data to Google Analytics and MixPanel, which do much more invasive levels of analysis in general.

Also in the same thread, you can download the no tracker version from F-droid.

Lastpass is the same way.

For those just scanning the comments, "full remote access" is just being used to mean "has an automatic update system" here

That's a very disingenuous way of putting it. If you use the application, there's auto update functionality (with a confirmation dialog box) if:

- You're on Windows and not using the Windows Store version or a "portable" version of the application - You're on macOS and not using the app store version - You're on Linux and you're using the AppImage version

Given the security-sensitive nature of the application and the target audience (mostly non-technical people), I think it's not a bad thing that this software has auto update functionality.

If you want to be free of this behaviour, you can either install the application through your system package manager/app store so you can control the update behaviour there, or run a development build of your vetted version of the source code.

You should read your own bug report for the way to disable auto-updates: either use the portable version or set the ELECTRON_NO_UPDATER=1 environment variable.