It's fascinating how Auth0 actually had a blog post about finding and fixing a handful of JWT vulnerabilities years ago (one of them is more advanced to exploit than this). Just another example of why you always have to be vigilant and that properly implementing encryption/security is hard
I think it's not just the journalists though...pretty sure some of the concerns with FB were published years ago but fell on mostly deaf ears. But now you have a public that cares more due to some "big revelations" and also a press he'll-bent on furthering the anti-SV tracking narrative
> Why would LE send the SNI in the first place? I thought the purpose was to prove you own the domain, not cohabit an environment where the domain is hosted?
The assumption was that you controlled the domain if you could return the self-signed cert with subjectAlt=foo.bar.acme.invalid when the SNI request for foo.bar.acme.invalid is made to the server your are requesting a cert for. Unfortunately the assumption didn't hold up because hosting providers shared the same routing server across domains and subdomains and those routing servers did not have controls around the subjectAlt domains used for TLS-SNI-01.
> Also, what do host headers have to do with this? Presumably this is just a tls handshake test?
They don't have anything to do with the weakness. It's mentioned to make the distinction that SNI is used for the cert retrieval to establish the connection and Host-header is used separately to route to the proper backend
> The green lines are flight paths from before the implementation of the new technology (January 2013). The red lines are flight paths from after the implementation of the new technology (January 2015).
if you store plaintext password on the client, you'd be one XSS attack away from potentially having a lot of passwords stolen - best practice is to have password in plaintext for a little as possible (there's some research on not transmitting the password at all but I don't think there's anything widely accepted like bcrypt is for password hashing https://en.wikipedia.org/wiki/Zero-knowledge_password_proof)
anything that makes computation less intensive for you also makes it less intensive for a potential malefactor - it's just an inherent tradeoff.
Rather than scan for password being contained in the message, something more reasonable to try would be to check if the whole message is the password since you can just plug that into the normal password hasher and run just one slower hash op
yeah, if you're absolutely inept and have insufficient logging/monitoring, you can't even tell how bad you'd been screwed. kinda like a Dunning Kruger effect of sorts
https://twitter.com/grubhub/status/611320394256109568?lang=e...