xianb
xianb on Hacker News
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
https://auth0.com/blog/critical-vulnerabilities-in-json-web-...
probably need to be fined billions to get them to take it seriously
Houzz and Nest security emails also got filtered
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
For ETH the big one is the DAO where they had to fork it to recover
There's also other smaller bugs like coinbase and parity wallet
Perhaps this might be a poor setup on my company's part, but it's awful navigating between teams and finding escalation policies and schedules in PD
> 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).
sounds like a nice generic company value/principle
is it really different from the data collection of other grocery store shopper cards though?
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
but you can also choose to withhold stock for taxes
basically would have just been a losing gamble to have withheld money instead instead of it being something forced upon them
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
sounded like the video stuff was added after view as was added so it probably didn't go through the same level of scrutiny
It's running fine for me on a Pi Zero W. There's honestly like no slowdown at all