sudneo

This statement makes no sense. Federated search means nothing. Ultimately someone needs to scrape, index, store and retrieve data. At the moment, a handful can do it efficiently, and to have a wide coverage, engines use also other APIs. Kagi does this, for example, by combining Google and others (e.g. brave) with their own indexer.

How do you imagine a "federated" search would be any different? Using multiple APIs is effectively "federating".

As I said in another comment, to be fully ethical you should not run on any major cloud (owned by Amazon, Google, Microsoft, Oracle and IBM), not run on anything on fossil fuels (few DCs), not use any API of major companies (google, apple, etc.) and so on. So basically if we ever want a new, better, solution (tech) we just need to materialize a few billions of dollars to allow this fully ethical solution with no dependency on immoral parties. Alternatively, the whole market dynamic should be disrupted, because that's the problem.

They are using brave search results, like they do with others. Frankly, you could build totally identical arguments (and to be honest, much more serious) for "partnering" with Google and Microsoft, but then the product wouldn't exist and wouldn't be as good.

The relationship with the Brave founder is so indirect, that this - to me - feels like an argument from someone who is looking for reasons to get angry. Kagi probably uses AWS (or other clouds), which funds Amazon (known for terrible worker rights), funds Google, fossil fuel industry, etc. It's a sad reality, but you simply can't exist nowadays in the moral and ethical way many people would like. You can, only if you are a privileged one. Technologically speaking, Google can probably do it, for example (own hardware, DCs, tech etc.). We can choose to fight those that directly support political agendas we disagree with, or we can damage the smallest players by demanding they will be 100% pure and ethical by not having any relationship with those with those agendas.

In my personal opinion, such unrealistic ethical requirements end up being a reactionary choice as they will ultimately impede new - better - players to emerge and will leave the existing - worse - dominating.

I noticed it yesterday by chance!

Kagi is a really good product that I am very happy to support.

As I said elsewhere, the company implemented this feature and apparently did not do absolutely jack about the increased risk of account compromise deriving from it. If I would sit in a meeting discussing this feature I would immediately say that accounts which share data with others are way too sensitive and at least these should have 2fa enforced. If you don't want it, you don't share data. Probably the company does not have a good security culture and this was not done.

It doesn't matter. It is a known attack and the company should have implemented measures against it.

At the very least, they should have made a threat modeling exercise and concluded that with this sharing feature, the compromise of a single account can lead to compromise of data for other users. One possible conclusion is that users who shared data should be forced to have 2fa.

It doesn't matter. It is a known attack and the company should have implemented measures against it.

At the very least, they should have made a threat modeling exercise and concluded that with this sharing feature, the compromise of a single account can lead to compromise of data for other users. One possible conclusion is that users who shared data should be forced to have 2fa.

Companies pay SMS, TOTP is free for them (just a computation...). It is utterly dumb to implement the same logic with a paid service rather than TOTP (or security keys, at this point). So yeah, I agree with the idea, but I think nowadays most 2fa is TOTPs (sadly, some require their shitty apps to do just that - Blizzard once was one of them, maybe still is).

I don't think it's possible to make a blanket statement in this sense. For example, Lemmy doesn't handle as sensitive data as 23andMe. In this case, it might be totally acceptable to have the feature, but not requiring it. Banks (at least in Europe) never let you login with just username and password. The definitely comply with different standards and in general, it is well understood that the sensitivity of the data (and actions) needs to be reflected into more severe controls against attacks which are relevant.

For a company with so sensitive data (such as 23andMe), their security model should have definitely included credential stuffing attacks, and therefore they should have implemented the measures that are recommended against this attack. Quoting from OWASP:

Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including credential stuffing and password spraying, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises. As such, it should be implemented wherever possible; however, depending on the audience of the application, it may not be practical or feasible to enforce the use of MFA.

In other words, unless 23andMe had specific reasons not to implement such control, they should have. If they simply chose to do so (because security is an afterthought, because that would have meant losing a few customers, etc.), it's their fault for not building a security posture appropriate for the risk they are subject to, and therefore they are responsible for it.

Obviously not every service should be worried about credential stuffing, therefore OWASP can't say "every account needs to have MFA". It is the responsibility of each organization (and their security department) to do the job of identifying the threats they are exposed to.

Yes, forced mfa (where forced means every user is required to configure it) is the most effective way. Other countermeasures can be effective, depending on how they are implemented and how the attackers carry out the attack. Rate limiting for example depends on arbitrary thresholds that attackers can bypass by slowing down and spreading the logins over multiple IPs. Other things you can do is preventing bots to access the system (captcha and similar - this is usually a service from CDNs), which can be also bypassed by farms and in some cases clever scripting. Login location detection is only useful if you can ask MFA afterwards and if it is combined with a solid device fingerprinting.

My guess in what went wrong in this case is that attackers spread the attack very nicely (rate limiting ineffective) and the mechanism to detect suspicious logins (country etc.) was too basic, and took into account too few and too generic data. Again, all these measures are only effective against dumb attackers. MFA (at most paired with strong device fingerprinting) is the only effective way there is, that's why it's on them to enforce, not offer, 2fa. They need to prevent the attack, not let just users take this decision.

If the accounts were logged into from geographically similar locations at normal volumes then it wouldn’t look too out of the ordinary.

I mean, device fingerprinting is used for this purpose. Then there is the geographic pattern, the IP reputation etc. Any difference -> ask MFA.

It’s so difficult that most companies tend to just defer to large players like Google and Microsoft to do this for them.

Cloudflare, Imperva, Akamai I believe all offer these services. These are some of the players who can help against this type of attack, plus of course in-house tools. If you decide to collect sensitive data, you should also provide appropriate security. If you don't want to pay for services, force MFA at every login.

Of course this is not a brute force attack, credentials stuffing is different from bruteforcing and I am well aware of it. What I am saying is that the "lockout period" or the rate limiting (useful against brute force attacks) for logins are both security measures that are sometimes demanded from companies. However, even in the case of bruteforcing, it's the user who picks a "brute-forceable" password. A 100 character password with numbers, letters, symbols and capital letters is essentially not possible to be bruteforced. The industry recognized however that it's the responsibility of organizations to implement protections from bruteforcing, even though users can already "protect themselves". So, why would it be different in the case of credentials stuffing? Of course, users can "protect themselves" by using unique passwords, but I still think that it's the responsibility of the company to implement appropriate controls against this attack, in the same exact way that it's their responsibility to implement a rate-limiting on logins or a lockout after N failed attempts. In case of stuffing attacks, MFA is the main control that should simply be enforced or at the very least required (e.g., via email - which is weak but better than nothing) when any new pattern in a login emerges (new device, for example). 23andMe failed to implement this, and blaming users is the same as blaming users for having their passwords bruteforced, when no rate-limiting, lockout period, complexity requirements etc. are implemented.

My idea is definitely biased by the fact that I am a security engineer by trade. I believe a company is ultimately responsible for the security of their users, even if the threat is the users' own behavior. The company is the one able to afford a security department who is competent about the attacks their users are exposed to and able to mitigate them (to a certain extent), and that's why you enforce things.

Very often companies use "ease" or "users don't like" to justify the absence of security measures such as enforced 2fa. However, this is their choice, who prioritize not pissing off (potentially) a small % of users for the price of more security for all users (especially the less proficient ones). It is a business choice that they need to be accountable for. I also want to stress that despite being mostly useless, different compliance standards also require measures that protect users who use simple or repeated passwords. That's why complexity requirements are sometimes demanded, or also the trivial bruteforce protection with lockout period (for example, most gambling licenses require both of these, and companies who don't enforce them cannot operate in a certain market). Preventing credentials stuffing is no different and if we look at OWASP recommendation, it's clear that enforcing MFA is the way to go, even if maybe in a way that it does not trigger all the time, which would have worked in this case.

It’s up to each user to determine how securely they want to protect their data.

Hard disagree. The company, i.e. the data processor, is the only one who has the full understanding of the data (sensitivity, amount, etc.) and a security department. That's the entity who needs to understand what threat actors exist for the users and implement controls appropriately. Would you trust a bank that allowed you to login and make bank transfers using just a login/password with no requirements whatsoever on the password and no brute force prevention?