OneDeuxTriSeiGo

It's not really misleading. A lot of people here use Bunny and this is a relevant security incident. It's not a major failing but rather a "hey shit happened come make sure if it applies to you that you respond in kind".

NGL it's the exact wording I'd personally like to see from a product that had an infra provider have an incident just so that I can mentally tune in enough to figure out if I need to care.

> That makes me wonder - I’m sure it’s not a novel thought - if there is a more suitable species of algae for these conditions we can inject into bleached corals?

TLDR Yes but it's complicated. There are more suitable algae species but AFAIK coral under heat stress will still often expel the algae even if the algae isn't the one stressing the coral. So you have to essentially breed a more tolerant coral and then provide the algae.

Now luckily there do exist more heat tolerant coral and algae species living alongside each other. Unfortunately those species are located in the Persian Gulf/inside the Strait of Hormuz so they are regularly subject to added stressors from Oil/NG extraction, military conflicts, and waste dumping. And of course their location makes research on them/collaboration between research institutions complicated.

And it's not like you can just transplant these coral somewhere else and they'll live. They are adapted to their environment and that environment plays a part in their heat tolerance as well. But research on these coral ecosystems will likely shed a light on how to help other coral species to adapt and evolve.

Yep this is exactly it. It's a sanity check that enforces the invariants so that when someone else violates those invariants and they don't know what went wrong they can easily debug it.

> That method still works just fine with passkeys right?

Kind of? But it really depends and there's a lot of edge cases the phishing website would have to dodge to avoid breaking the custody chain.

If you force the user down to "use your password/security questions/whatever" to auth and create a new key then yes phishing is still viable here but one of the key advantages of pushing for a passkeys-first approach is that you can make the other auth methods harder. i.e. mandate password + 2FA as a strictly backup method instead.

> The key problem is that sites have made users so used to having to generate a new password/credential that they think nothing of it. It's something you just do every few months for most websites esp. secure websites like banks.

Yep and passkeys explicitly exist to eliminate this behavior.

> Even on the same device users are being trained to generate multiple passkeys, one for chrome, one for safari/apple, how about a third for the phishing site.

Well here the caveat is that the phishing website would have to force the user back down to password-auth or security questions or whatever other "weak" method and then use that to create a passkey but not have perms to do anything else.

Now if the phishing site tries to MITM the actual passkey registration flow there are a lot of ways to detect a phishing attempt and terminate the registration and alert the user through alternate contact methods.

TLDR: there are probably still ways to execute a phishing attack but to succeed they have to be far more sophisticated and there's countless ways to accidentally break the passkey auth chain in a way that halts the attack.

? If a website sucks and can't support multiple passkeys that's not a flaw of passkeys. It's a flaw of the website. You could make the exact same argument for TLS or 2FA or every other security feature.

If the developer fucks up the website/app, that is their fault and not a failure of the technology.

> Is it input validation to say a string must be at least some length characters

Yes. Yes it is. Input validation should happen at the public API and then contracts after that.

Contracts are very explicitly for things you don't want to ever see happen. They are "something went wrong".

So your API would accept a function that handles input validation and maybe has its own contract for things it explicitly doesn't handle but then internally you use contracts to enforce that the string is already input validated and you don't have to enforce edge cases.

Strictly speaking you put them in the header.

The first declaration of a function must include the contract pre/post conditions and follow-up re-declarations of the function must either not include any contract conditions or the same conditions as the initial declaration.

And you can avoid re-including the world because pre/post conditions should be externally visible behavior or call out to functions for pre/post checks on internal behavior.

Essentially you either define them using what you have in scope during the initial declaration or you call out to a function located elsewhere that can have access to more/internal scope and do more complicated checks.

nah contract_assert has entirely different semantics than normal asserts.

It includes checkpoint semantics (something that is part of contracts in general) as well as processing through the contract violation handlers.

Functionally contract_assert should eliminate the need to use assert at all and is an over all substantial UX improvement.

contracts are intended to document hoare logic. i.e. pre, post, invariant.

They can be compile time if the compiler can verify them statically (where they become a noop), runtime otherwise, or disabled entirely if you can't prove them statically but don't want the overhead cost.

Realistically contracts will gradually evolve towards static/compile time asserts as tooling improves.

And like the blog post states, contracts are explicitly not input validation. They are there to encode what you expect and what you don't internally in your code rather than just documenting those pre/post/invariant conditions in comments.

?

That's not the argument being made.

The argument I'm making is that the only MITM/phishing vulnerability is in the initial passkey registration and not in the auth.

So once you have a passkey and the flow supports attestation, as long as you use the passkey you are effectively immune to MITM and phishing.

Now if you input a password or recovery code or whatever and use that to register a new passkey that's initial passkey registration again and not MITM or phishing of the passkey itself. The reason this matters is because you can register as many passkeys as you want. Say you sign up and log in on your phone. Now you register a passkey on the phone. You want to log in on your laptop, use the key from your phone to log in and register one for the laptop as well. Now you lose your phone or your laptop, you use the other to log you in and set up a new passkey for that device.

Once that initial passkey was registered the auth process is pretty watertight and each device you regularly use gets a new key after auth so you generally always have at least one device that you can use to get into your others.

Now of course if you only have one device and it gets destroyed or if all your devices are destroyed in a fire or flood or whatever then you have to go through the untrusted reset/re-registration flow but in all other scenarios you always default to the passkey-based "use another device you own" methods to register new keys.

TLDR: the point is that you very rarely ever do a true cred reset. The flow itself incentivizes multiple passkey auth methods such that bootstrapping new keys from an untrusted environment is rarely if ever required. This works best for "core services" like your email/google acct/apple acct/microsoft acct where you are generally expected to want access to them anywhere you do stuff so the passkey flow is best pared with SSO to increase the odds you've used the acct on at least one other device.

Strictly speaking it's mainly hardware attestation but it's technically "hardware based passkeys" and "remote attestation". So if you rely on attestation in general and don't restrict the attestation source it works just as well.

Software passkeys can be stolen if the client is compromised but they aren't vulnerable to MITM or phishing as long as attestation is used.

> which enclaves/sources/devices do you support vs. not support?

You support all of them and prefer the strongest configuration for the source available.

If you've registered a hardware based key with attestation and then an attack tries to intercept that via phishing or MITM, the key already has its capabilities established and if you try to use the key without attest it should fail.

If you register a key without attestation support then you may be vulnerable to MITM or phishing but you can't intercept a user/their passkey with a stronger set of capabilities and downgrade them.

Yes. You can register as many different passkeys as you want. Any limitation in passkeys registration quantity is a limitation of the website/app itself and not a limit of the spec, etc.

> They are still susceptible to malicious enrollment. If a user is convinced a fake site is real, to the point that they are opening their password manager to copy the password to it, you should assume they will do the equivalent with a passkey (re-enroll attacker's key or register attacker's passkey).

This is only technically true because of the definition of what a passkey is is vague.

Hardware Attestation solves this problem and is "good actually". The issue with attestation is when site attempt to restrict which enclaves/sources can register keys. But if you don't restrict who/what can register keys, attestation is super useful for preventing this exact issue.

When you register your key initially you establish your hardware attestation parameters. The attacker cannot know those parameters unless they were the ones to initially register you for the site as the public attestation signature is unique per-key and the private one per-use with the public one verifying the private one.

So if you have remote attestation you can verify whether the source presenting the signature for auth is the same source that created the signature and trivially block MITM attacks. Likewise for more complicated custody/proxy chains.

This just by itself largely solves MITM key re-enrollment attacks but tech camps that support passkeys either ideologically oppose attestation (due to understandable enclosure fears) or enforce hardware attestation for enclosure purposes without bothering to address MITM/signature origin checks.

> is not the Holocaust

Hitler and Nazi Germany did not start with the Holocaust. It was instead the end result. Something can be compared to Hitler or compared to the Nazis or their rhetoric without being literally the Holocaust.

Keep in mind that Hitler and the Nazis took power starting in 1933 but forcing jews to carry identification (i.e. add israel or sara to non-jewish names and add jewish identification marks to paperwork) didn't start until mid-to-late 1938 with Kristallnacht following only months later in Nov 1938.

But in that early period however Nazis began

- gutting research institution

- literally destroying research institutions and research. (ex the famous 1933 book burning picture was from the demolition of the Institute for Sexual Research which studied gender non conformity, intersex traits, and broader topics in the LGBTQIA academic space. Also was where the first transgender sex reassignment surgery took place.)

- expelling academics

- dismantling social programs

- pressuring companies into aligning with state ideological and industrial objectives

- seizing control of, attacking, or privatising domestic and foreign media

- pressuring domestic and foreign entertainment into aligning with Nazi ideological stances

- punishing, oppressing, and expelling political and cultural enemies of the party from the military and civic institutions.

- converting prisons into work camps.

- building out detention facilities/prisons for "illegals" with deplorable conditions with intent to make them suffer as long as possible. These would later become concentration camps and then death camps once crowding became too extreme. And notably this began with the romani population in the early 1930s who Nazis believed to be criminals illegally present within the country.

--------------------

Nazi germany was so much more than just the Holocaust and genocide of the Jewish people. They were part of it however they were the conclusion not the start.