111–120 of 258 posts
Earlier quoted context omitted.
Starting today, this will be known as "Shanghai'd credentials" and be reason #1 why we use ephemeral credentials (e.g. AWS STS/SSO) rather than static credentials (e.g. IAM Users)
Doesn't the client still need to know a long-lived secret (or a long-lived refresh token) in order to generate the ephemeral credentials?
You add the long lived IAM user API key/secret to it and it stores it in a password protected storage (MacOS keychain or similar).
Then you invoke aws-vault with an IAM role and command, and it will handle obtaining short-lived credentials scoped to that role (including TOTP 2-factor code auth), and then run the command with those temporary credentials as env vars.
With the right AWS permissions on your user, it can also automatically rotate the IAM user API keys for you.
Earlier quoted context omitted.
In history what have databases of people and state actor interests usually led to if any events are similar?
IIRC when Nazi Germany invaded Denmark in 1940, one of the first things the SS did was to send representatives to the local churches. In Denmark, every child was (I’m not sure if they still are actually?) registered at birth by the local parish in so called “church books”. With these “databases” in hand, the SS had a neat list of all names, and the approximate location of peoples homes. Those lists were used to ident…
Earlier quoted context omitted.
"Fun" fact: It was IBM who helped tabulate data from the 1933 national census, which was then used to identify hundreds of thousands more Jews than would have been found by the Nazi party without their efforts. "Machine-tabulated census data greatly expanded the estimated number of Jews in Germany by identifying individuals with only one or a few Jewish ancestors. Previous estimates of 400,000 to 600,000 were abandon…
And to add insult to injury, the IBM office in Munich (birthplace of national socialism), is located on 1 Hollerithstrasse (Hollerith street). The IBM subsidiary in Nazi Germany selling and maintaining the tabulating machines was DeHoMag, Deutsche Hollerith Maschinen AG. ...
Earlier quoted context omitted.
It's incredibly disappointing actually how often this happens. I can't count the amount of SO questions I've had to edit from others posting live API Keys for everything from custom services to AWS.
I wonder if you could make a luhn-like check that would require an additional approval step to post if it comes back positive. Something like "It looks like you may be posting a secret *****. Do you wish to continue?
Of course, then your secret key checker would need to build that string by concatenating so that it wouldn't set off itself.
Earlier quoted context omitted.
It is both. It is huge, I'd say it's absolutely the latter. but I can't think of a single thing anyone can do about any of it at this point, which also makes it the former.
One thing I’ve thought about doing is using CCPA to have companies delete all my data, hopefully before it leaks.
Also they keep the record of the delete request, which contains the PII you ask to remove.
Karen Hao (WSJ): "I downloaded the sample the hacker provided and called dozens of people listed. Nine picked up & confirmed exactly what the data said." https://twitter.com/_KarenHao/status/1543949945614393344 (thread)
nitter link, since Twitter put up what seems to be a timed login gate when I was halfway through reading the thread: https://nitter.net/_KarenHao/status/1543949945614393344
Earlier quoted context omitted.
The previous big case I remember was linkedin leak with 700M users: https://news.ycombinator.com/item?id=27674393 At this point I've basically accepted that all my info will be found on sites like fastpeoplesearch.com and that anything I tell any company (or I guess in this case, govt too) will eventually be leaked, correlated, and used against me.
Wow that's bigger than Equifax
Earlier quoted context omitted.
Starting today, this will be known as "Shanghai'd credentials" and be reason #1 why we use ephemeral credentials (e.g. AWS STS/SSO) rather than static credentials (e.g. IAM Users)
Doesn't the client still need to know a long-lived secret (or a long-lived refresh token) in order to generate the ephemeral credentials?
For example, for AWS you can create long lived credentials for users which are scoped to only allow one operation, namely obtaining a short lived token (with the aid of a hardware token such as a Yubikey) with scope to perform other operations.
AWS guide here: https://aws.amazon.com/blogs/security/enhance-programmatic-a...
Earlier quoted context omitted.
The previous big case I remember was linkedin leak with 700M users: https://news.ycombinator.com/item?id=27674393 At this point I've basically accepted that all my info will be found on sites like fastpeoplesearch.com and that anything I tell any company (or I guess in this case, govt too) will eventually be leaked, correlated, and used against me.
Wow that's bigger than Equifax