"Crippled" is a big word. It does everything that KeePass would do, for example; it only falls short when it comes to sharing passwords among a group or family (you can send a secret via BW Send, but you cannot have a shared store unless you pay for Premium).
Yubikey and its likes are advanced features that the overwhelming majority of regular users will never need.
"Crippled" implies a degree of everyday suffering in the "cripple", or a downgrade from a previous state of health. The advanced features in Bitwarden were never free, in fact I think some of them were eventually added to free plans too. I honestly don't even want stuff like yubikey support, and could see that as feature bloat!
I don't expect everything to be free, I'm perfectly fine with the freemium model when the set of free features is reasonable - as, in my humble opinion, is the case with Bitwarden. So I wouldn't use a word like "crippled" when it's more like "normal for regular users vs enhanced for advanced needs".
I thought that it had all the same features, just not cloud sync. As far as I know the Yubikey is used for authenticating with their sync server. It doesn't actually help with the encryption
Bitwarden's free plan does have end-to-end encrypted cloud sync with no device limit. The free plan lacks TOTP support, but Bitwarden's $10/year plan does include TOTP support and is cheaper than 1Password's $35.88/year plan. Bitwarden is also open source, while 1Password is not.
I'm referring to Bitwarden Authenticator, which stores TOTP secrets and displays 6-digit codes like Google Authenticator does.[1] This feature requires a Bitwarden Premium account, with the $10/year plan being the cheapest option.[2] (Self-hosting through Vaultwarden is another option.[3])
This is separate from having TOTP 2FA on the Bitwarden account itself, which is available on the free plan.[4]
Why would you have to guess when the source describe it. Anyway, funny how you mention "only"- the "only" increase in trackability is to be able to retrieve user information about users using the world's most popular online services. I don't want pornhub to be able to view my photo from Google. Comparing this to CSS fingerprinting seems misinformed at best.
* Finding your browsing history: historically this was just as trivial as the DB name leak
* Finding the google ID: this is the bigger issue and provides a very concrete way of tracking a specific user.
I was trying (admittedly terribly) to say the browsing history is not the worst bug in the grand history of the web, although it is very clearly bad.
The bigger issue is the google tracking ID being leaked to third parties.
[edit: I incorrectly claimed there was a google id when you weren't using a google account, forgetting of course that YouTube is part of google. herp derp. I work in tech and use to work on a browser engine]
I might be misunderstanding you, but it's a leak of database name, not database contents. You can tell someone visited a website by looking at the name, but your photo from Google is safe.
I'm so confused now. Did you read about the issue? I wonder if I misunderstood maybe.
As I understand it:
According to the source, Google inserts unique user ID is into database name. An attacker can make a request to Google, pass in this unique user ID into their API and get profile details, for example a photo back.
The attacker does not need access to the database data, only the database name, since the user ID is embedded in the _name_.
You are right it's a leak of a database name, but Google store sensitive data in the database name.
My reading was that a user can be identified by the userid. I'm not sure what other actions just having an userid authorizes, but I would lay that bit on google.
There are clearly two issues here, only the first one of which has been demonstrated. One is the leak of database names, which is on Apple. The other one is releasing sensitive data on insufficient authorisation(just an user id), which would be on google.
* Connecting from my own IP with wrong password: It tells me to "Check my master password and try again."
* Connecting from another IP with wrong password: It tells me to "Check your inbox for an email from LastPass: <myemail**@gmail.com>" and also to check my login info.
It's a bit odd that it tells me to check my email even though the master password I provided was incorrect.
Yeah, it's as if the error message (when using a wrong password on a new IP) was trying to not say that the password is wrong. It's just saying "check your email", just as if you had typed in the correct password (from a new IP).
But when you did attempt to login with a wrong password, you never received a "Someone just used your master password to try to log in to your account from a device or location we didn't recognize" email, correct?
That would truly be the best outcome possible -- that LastPass sent out "Someone just used your master password" emails incorrectly i.e. those were false positives.
They are saying it’s just a credential stuffing attack and being that my master passphrase is only used for LastPass I’m hoping that is all that is going on. Their statement does say “It’s important to note that, at this time, we do not have any indication that accounts were successfully accessed” but I would still like confirmation the emails were sent even on invalid attempts.
But if your master passphrase is only used for LastPass (as is exactly my case -- I've never used it elsewhere), how can it can be credential stuffing? Or was the password breached from LastPass itself in the past? That's possible, but then it doesn't jell with people having this same issue with accounts created in November 2021.
As far as I can tell, the "Someone just used your master password to try to log in to your account from a device or location we didn't recognize" email we all received was only sent when a correct password was used. Incorrect passwords did not trigger that email.
But yes, it would be great to learn that those emails were sent incorrectly i.e. it was a false positive (i.e. someone tried to login with a wrong password, but the email above was sent anyway). It's still not great that the wrong kind of email was sent, but that would be a low level bug.
I was never able to successfully trigger the false positive last night but I believe the most recent explanation from LastPass is in line with what I have been seeing. Intermittent false positive emails.
Yeah, just saw their new announcement (thanks for doing those tests yesterday by the way!)
I don't know how much to read into their use of "some" and "likely" i.e. "some of these security alerts, which were sent to a limited subset of LastPass users, were likely triggered in error"
I would want to know whether they can demonstrate that wrong passwords were used in this attack. And have an explanation for those users who received the email a 2nd time after changing their passwords.
Could it be that some malware were run on your machines recently (say a few weeks ago) which extracted the master passwords and then used it now? If your LastPass master password was stored on your computer then malware could have collected it and sent it off to some attacker.
Or could it be that all of you guys are using the same router, same ISP, same anything-else, which has snooped on traffic and collected the credential?
Malware is not impossible, but in my case, the password is stored in an encrypted keepass file. Did the malware wait for me to open my keepass vault and snoop the password then? Possibly. But it presumably could/would have done much worse things.
Other people in this thread are also confirming that their password was unused anywhere else.
And as more independent people are reporting the same story happening to them, the less probable it is that we were all hit with the same malware. It's looking more and more like this is something happening on the LastPass side.
A router/ISP should not be able to snoop the traffic between us and LastPass as presumably it's encrypted.
Let me preface by saying I'm speculating of course.
> Did the malware wait for me to open my keepass vault and snoop the password then?
It's not impossible at least. There's been vulnerabilities in Keepass RPC which allowed any javascripts on Internet reading your passwords [1]. If a simple javascript can read secrets from keepass, I would not be at all surprised if that has happened.
> the less probable it is that we were all hit with the same malware.
Sure. But there's also some selection bias here, were a lot of people visiting hackernews is affected. On twitter, everyone (more or less) who's discussing this issue links this post, which at least in theory could indicate that the scope of the issue is relatively narrow (compared to the entire internet). It could be that some specific developer tools or libraries have been affected for example (as any of the recent packages on NPM which people claim may have sniffed credentials).
I copy/pasted the password from 1Password, it may lend credence to the malware Chrome extension theory, at least in my case. Anybody else using these?
uBlock Origin, Google Images Restored, Allow Right-Click, Clear Cache, StartMeeting.com Launcher, ShowPassword, Tampermonkey, Usability Hike: Find usability problems, Window Resizer, Tag Assistant Companion, Google Analytics Debugger, Google Docs Offline, Google Optimize, Google Suspicious Site Reporter
I use uBlock Origin too (only one in common with you), but in my case, I hadn't copied/used the master password before the login attempt
The login attempt was out of the blue, using a password I hadn't used since 2017.
My LastPass password may have been compromised back in 2017, but there are at least two reports here of recent accounts being compromised as well (with the attacker connecting from the same 160... IP range)
happened to me too, the only one there I have is uBlock origin, matched what somebody also had. Hard to imagine it's ublock origin though because it has so many users.
Couldn't it just be that someone got a copy of the password some years ago and now sold the list of credentials to someone else, who then tried to use it? Maybe the original owner of the list didn't realize some of the credentials was for LastPass, for example.
I'm still seeing hackers trying to log on using passwords I haven't used in ~10 years, because it's on a list somewhere.
So LastPass (their extension) may have been hacked ~5 years ago ish, a few people here on the thread were all hacked in the same way, our passwords were sold off, and now the same Brazil IP range just tried all of those passwords.
I've been trying to ask this to people posting reports, and although there are many "older" accounts (like mine, circa 2017 or older), at least 2 reports are from accounts created this year:
This sort of attack will get you banned here, regardless of how right you are or feel you are. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it. Note this one:
"When disagreeing, please reply to the argument instead of calling names. 'That is idiotic; 1 + 1 is 2, not 3' can be shortened to '1 + 1 is 2, not 3."
and this one:
"Please don't sneer, including at the rest of the community."
People on HN are completly crazy and uneducated... Whenever there is something like this you can be sure you will find hundreds of insulting or mean comments on the commit or PR... It gives a really bad image of the community.
This sort of name-calling breaks the site guidelines badly, regardless of how right you are, or how superior you feel to the rest of the community. If you'd please review https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
If the box is designed for that purpose then it's designed for that purpose. Then it's not plain wrong. The article is not saying that all the kids have an equal start in life so not sure where you got that from.
Your reasoning is like saying Red Cross isn't designed to reduce the suffering of people because there are still suffering people. It's an odd claim to make.
