* HTTP/2 (3?) (on the roadmap)
* a refresh of the dyno line-up - at least pass on some of the cost savings of removing/supporting free tier by reducing dyno pricing or preferably bumping specs
* auto-scale for all dyno tiers
* rebuild security team with reputable lead
* edge / multi region active-active DX
* edge ssl termination
* iterate on chat ops (underrated feature)
* more metrics
* more alerting (e.g. crashed apps)
* better user/access team management (default app roles)
* enhanced secrets management in env (2 layers of env view/roles - config vs secrets)
* DDOS protection
* Treat CI env vars as secrets!
>If you used your previous password on any other sites, we highly recommend you also change your password on those sites.
This is the most concerning part of that email, as it implies more than an "out of an abundance of caution", but rather that they suspect their password DB has been compromised.
Thinking about it, it does sound the most likely as they were probably the same DB the customer oAuth tokens were stored in that were used to access Github repositories. But if they already knew the data was stored together why wait till now to reset passwords?
Just to verify - having TOTP-based 2FA enabled doesn't help in case of a password DB breach, right? Since the protocol is based on a shared password, which means an attacker would be able to generate valid tokens using the secret they got from the breach. (looks like there's work underway to make a breach-resistant alternative to TOTP[1])
This means that assuming the DB is using proper salt+hash, the main differentiator is the strength of your password. If it's a relatively short one that can be brute-forced/found via dictionary+small mutation, then attackers could possibly log in as you. If it's a strong password from a password manager, then that will likely have kept them from being able to crack your password.
Of course all this only has value if we assume that only the password db was breached. If they managed to access the place your env-var/secrets are stored, then all bets are off.
I don't understand enough about the protocol to judge your claim, but it's challenging my assumptions about what 2FA is for. If 2FA with TOTP does not protect you in cases where the attacker knows your password... what is it for? I thought that's what it was for.
The server also contains the secret, so if that secret is leaked then the attacker can generate new tokens. It protects you in the case that your password was stolen, but nothing else e.g. via phishing.
OH, I see, thanks. The password and TOTP secret are separate, but you're suggesting they may likely both be stored in the same place such that a breach could give attacker access to both. Tell me if I don't have it right.
It occurs to me that I know how to reset my password most places I log in to, but I actually have no idea how to reset the TOTP secret.
> Support engineers use a number of customer support tools to get their job done including Okta’s instances of Jira, Slack, Splunk, RingCentral, and support tickets through Salesforce.
I like how it just glosses over access to all the other tools which often contain a treasure trove of data. Just Slack can give an attacker worst case credentials pasted into channels and best case loads of information for more targeted social engineering attacks. LAPSUS$ even stated they had access to over 8K channels.
Reading the other trending article on LAPSUS$ (https://news.ycombinator.com/item?id=30774406), access to Slack suits their MO perfectly in terms of mining it for data for more sophisticated escalation of access via social engineering.
Has Google Analytics now adopted the latest European Commission approved SCCs (https://ec.europa.eu/info/law/law-topic/data-protection/inte...) and does that mean using GA with those SCC's is now compliant going forwards. Or does this cases verdict that "SCCs and "TOMs" not enough" now mean those EC approved SCCs are now useless?
This case is explicitly about US Law and how it contradicts the EU law. According to this case, as long as US law allows the US government to force US companies to share data with the US Government then you can't share data with those US companies.
To quote directly-
> SCCs and "TOMs" not enough. While Google has made submissions claiming that has implemented "Technical and Organizational Measures" ("TOMs"), which included ideas like having fences around data centers, reviewing requests or having baseline encryption, the DSB has rejected these measures as absolutely useless when it comes to US surveillance (page 38 and 39 of the decision):
> "With regard to the contractual and organizational measures outlined, it is not apparent, to what extent [the measure] are effective in the sense of the above considerations."
> "Insofar as the technical measures are concerned, it is also not recognizable (...) to what extent [the measure] would actually prevent or limit access by U.S. intelligence agencies considering U.S. law."
Exactly my point. However the European Commission has released "Approved" SCC's in June 2021. Does this case now invalidate those because "the DSB has rejected these measures as absolutely useless when it comes to US surveillance" in which case it is in conflict with the European Commissions guidance.
My ideal goes further than that. All I want is a reasonable data plan with non extortionate roaming rates from my existing provider (phone service is not important to me these days due to FaceTime/WhatsApp/etc). Some providers were starting to offer decent roaming to a large selection of countries that came out of your existing allowance with no additional charge but they seem to have started rolling back on that now as margins are getting squeezed. There is no reason for roaming charges for 1 week to be higher than the cost of a 1 month pre-paid local sim.
I don't know the rollout process but perhaps it involves taking servers offline, putting more load on the still live unpatched servers, increasing the probability of the race condition occurring?
I continue to hold the view that Tesla's success is because they are really a software company, not a car company.