Detailed Financial Histories Exposed for Thousands
upguard.com
upguard.com
There is so much wrong with a national identity card. For example, who will pay for it? I don't want to pay for it. I don't want my taxes to pay for it. Even if you find some way to pay for it, I don't want it. What's next? Will you require me to carry a identity card on me at all times? "Random" cavity search for people walking down the road?
We can solve this problem by requiring lenders to be responsible for the debt they issue. Their word against mine? Debt is invalid.
Sounds like you are not open to discussing this.
Also, what does a national ID card have to do with "cavity searches"?
Edit: I understand the American insistence on reducing the reach of the federal government. What I don't understand is how many of those same people are fine with allowing Congress to screw us all over on important issues like healthcare and taxation...
Should I be open to discussing everything? Why? Personally, as long as this Congress is in session I think we should block every single new legislative idea because I can't trust it to do anything right.
> What I don't understand is how many of those same people are fine with allowing Congress to screw us all over on important issues like healthcare and taxation...
I don't either. Which is why I think they will manage to mismanage this. Remember, getting health care dot gov up and running took heroic efforts of a lot of people. Just something simple as getting a dot gov website (department of education to be exact) took years. The Path station at World Trade Center was 100% over budget at FOUR BILLION DOLLARS. Nobody cares. It isn't my problem, right? We talk about net neutrality and how we gave over $400B to telecoms to deploy fiber across the nation (which to their credit, they did but what about the last mile?). And about health care, I am sorry but Obamacare doesn't even go far enough to call it an achievement. Apparently, even Germany spends less (as a portion of its GDP) on healthcare than we do. This is insane. The main point of the matter is costs have to come down. People get mad when I say while minimum wages should go up, wages and salaries in general should come down. Credits and deductions should go away when it comes to taxes. Yet, the people who want a "simplified" tax code get up in arms when they can't deduct their house or their car from their income... Why can't I deduct my rent? Why can't I deduct my cost of commute? Why should I? There is no rhyme or reason when it comes to taxes. It seems like it is just about who can push their way through...
Why not? If an idea can't withstand a debate, that says a lot about the idea.
And if keeping citizens secure is not the job of the government and thus paid for with taxes, then what is?
It's like if someone says "I fancy Chinese takeaway" and you don't want any you say "enjoy your cavity search" as if that's a natural outcome.
Explain.
Moreover, how is identifying yourself to the police bad? Sure if you live in a fascist dictatorship, but in a Western democracy?
Do we even live in the same country? https://en.wikipedia.org/wiki/Stop-and-frisk_in_New_York_Cit...
I genuinely can't see what your point is about Stop-and-Frisk?l
"I don't want to pay" is not a valid reason. I would not like to pay taxes but that's not how things work
It's mostly used to check your identity if the police stops you while driving, which is a little annoying because surely they could just check that electronically, but it's probably a legacy system. You also use it to verify your age when buying alcohol because driving license is not a valid form of ID.
It's not really a problem, I have mine in my wallet and never take it out, it's been sitting there for years. You can only really get in trouble if you don't have it while driving, and in that case I probably won't have my driving license either because it's in my wallet as well.
... while in other contries there is an ongoing discussion about whether it is against the Constitution to (begin to) require to show an ID when voting!
https://www.engadget.com/2017/11/04/estonia-freezes-resident...
It’s your right to live without one.
You just can’t get on a plane, get a drivers license, get your tax refund or get a student loan without it.
It’s a chicken and egg problem.
How do you map a public key to a person?
You will have to have an Equifax like service that will do the mapping.
But then how do you prove to them that you are who you say you are in order to map you to your public key?
Back to, SSN, driving license and what not.
Edit: I don't think having a governmental service dealing with thousands of people every day(lost keys etc..) is something that is going to happen in the US.
The public keys can be stolen all day long and they're the only part of the equation that needs to be stored anywhere long term. The private keys are just that; truly private, and ideally extremely difficult to steal.
Yes, there will need to be a public service to manage the public keys, and yes this will be able to be compromised in some dangerous ways, but not quite so dangerous as "Whoops, everyone's SSNs are lost, now any attacker can impersonate them because that's all they needed."
This is even before we talk about how to handle the huge number of people who will lose or delete them.
Tech can't solve this prpblem. Any system that requires a secret won't be.
The "only" other problem that will remain is that you will need a secure supply-chain, otherwise this will happen:
http://www.zdnet.com/article/id-card-security-spain-is-facin...
https://www.reuters.com/article/us-gemalto-cybercrime/hack-g...
If you do something like this you actually need to be serious about it and establish a rigorous vetting/auditing process -- not just hand the contract to whoever donated the most to your election campaign.
Maybe set-up a 3-year long NIST competition or something, like they do when choosing new crypto standards, and establish the winner this way.
The other side of the equation, allowing services to interface with these cards securely, is already being solved by the FIDO 2.0 spec.
Standards like FIDO and others allow for browsers and websites to utilize these cryptographic functions of smart cards in ways to handle website authentication. The technology exists for smartcards to handle authentication, it is simply a matter of us moving to this technology.
USB smart card readers are fairly cheap. Many business-focused laptops have been available with smart card reader options for many years.
Most modern phones have secure elements that can generate and store a private key that cannot be extracted through software. Also, it is easy to set up things such that a physical confirmation is required to sign something (this is eg. what some U2F keys or touch ID do).
Of course, you still need a procedure to map public keys to identities and people need to secure their phones in order to prevent someone stealing the phone to make signatures.
But using the secure element of a phone for various forms of authentication is orders of magnitude safer than relying on a credit card or social security number.
The USPS is nowhere near equipped to handle this. And there's no way I'd trust them to be competent enough to handle the task with the level of security that it would entail.
> They already provide a physical-to-identity "mapping" service for the vast majority of Americans.
They really don't. Even if we ignore the fact that one's identity is completely separate from the question of where they reside, the USPS has no way to verify residence. They don't really even a way to verify mailing addresses, which is at least a more well-defined problem than residence.
Why? Obviously it would be a big undertaking, but the post office already issues US Passports. I'm not sure what you mean by "verifying mailing addresses" because the USPS does provide a way to do verify the correctness and deliverability of an address [1].
The point is that the USPS would be in a good position to become the government body that implements a national identity service.
The State Department issues US Passports, the Post Office merely accepts your applications on their behalf.
> I'm not sure what you mean by "verifying mailing addresses" because the USPS does provide a way to do verify the correctness and deliverability of an address [1].
It's only vaguely tied to identity. I have my physical address, but because I live in an RV park and move often, I don't actually receive mail there. In about half of the locations I've stayed, you _can't_ receive mail there.
I use a private mailbox along with a mail forwarding service in order to receive postal mail.
> [1] https://en.wikipedia.org/wiki/Address_Management_System
Is used to solve the problem of sorting and routing mail, which is really what the Post Office spends most of their effort on. Every postal address in the US can be uniquely identified by an 11 digit code: your ZIP+4 and the last two digits of your house number, but it completely ignores multi-tenancy and has no provisions for linking to identity.
Is that more market ideology ("public services are by necessity so dumb") speaking, or is there something specific with the US postal service?
The US Post Postal Service is most certainly not in a unique position to "pivot" to being an identity and "trust" provider."
It's actually quite unbelievable to think that a bloated organization with 500K employees[1] that relies on manual and mechanical processes can "pivot" to become a tech organization providing digital identity management.
The USPS "pivoted" to delivering junk mail for direct marketers years ago. Given that there largest customer is direct marketing, that alone makes them rather unfit to be an "identify provider."
The USPS government mandate is delivering mail and despite having a government sponsored monopoly to deliver mail to mailboxes it still loses money hand over fist[2].
[1] https://about.usps.com/who-we-are/postal-history/employees-s...
[2] https://www.investors.com/politics/commentary/postal-service...
At least a public key can not be forged without my direct effort.
That's like saying how do you map a bitcoin to a person. Public Private key cryptography and the blockchain. Works great for bitcoins, would work great for identity.
In Slovenia where I'm from you have to go to a government location, same place that gives out IDs and passports and such, show your government issued ID and sign some paperwork. You are then given a digital certificate that you can use for online banking and e-government stuff. Proper RSA stuff. You install it on your computer and your browser uses it to sign requests.
Seems like a pretty good way to do it, if you ask me.
A slightly more efficient, if less secure, way is how Apple does it for their Apple Developer program. You have to prove to Apple in a way they like that you are who you say you are, then you are issued a certificate with which to sign your apps. That could work too.
The part I liked about the system in Slovenia isn't so much the particulars of where or how the certificate is stored, but about how it's issued. Since the bit I was answering was "But how do you map a key to a person"
Perhaps a better approach regardless of how it's stored is notification of use?
You do that in person, at the fed/state agency, using facial tech, fingerprints, etc. Once you prove who you are, you get to submit a public key to the agency, which you can revoke at any point -- you take a unique key from them too, and some combination of the two you use when signing up for new financial accounts.
While you might not personally believe this to be true, it's not a good design decision to enforce upon the entire world a concept of identity that many security professionals will tell you is broken at scale.
This doesn't even address key management issues such rotation, theft, loss, planting, etc.
First, ibGib's structure is like a block chain. I've been developing it for a long time, and I had no idea what a block chain was, and the like. But an ibGib's structure is like this:
* ib - unstructured text, like a name.
* often provides data or metadata for convenience per use case, i.e. data is just in the address, without loading entire record.
* ib + gib (ib^gib) is a "content address", but I think of it as like a memory pointer in an infinite memory space.
* Currently sha256 but that is metadata and can be specified in the data section.
* rel8ns - named "merkle" links to other ib^gib.
* special rel8ns include...
* "past" - provides a linked list of mutations
* "ancestor" - provides linked list of forks
* "dna" - provides event-sourcing-like complete history of how to build the record.
So, it's effectively like a tree-version of a block chain, or a distributed (and scalable) block chain. Or if you're familiar with IPFS (which is where I learned the term "merkle"), it's like a merkle forest. (I've been working on ibGib for 15+ years though - had never heard of IPFS either, but I digress). Basically, you can think of the entire thing as self-similar git repos, but for anything - not just code (currently working on VCS use case for it, which is why I've taken the code off of GitHub. You can see my current "issue" for it at https://www.ibgib.com/as-chat/version%20control%20in%20ibGib...).
So this works with identity in a different way, in that each record is internally associated with multiple identity ibGibs. For the above example, check out the "identity" key in the "rel8ns" section. So, each individual datum is associated with _multiple_ identities for multiple things: users, nodes, sessions, etc. The piece I'm working on right now (in the active process of whiteboarding/coding at this very second) is the public key infrastructure "replacement". Because the data has this entire integrity chain, you can do different things for verifying provenance.
The way that you "prove" who you are is similar to the current SPHINCS algorithm (https://sphincs.cr.yp.to/ or ), which is an ever-expanding many-times hash-based signature scheme. In my algorithm though, you can create "keystones" which act similarly to public/private key pairs. Each stone has a list of hash challenges and the specs of the challenge difficulty. For example, if I have a stone of 100 challenges, the stone may say that a valid challenge requires a minimum of 5 challenges to be answered. The challenges are based on 1-way hashes (recursively called with a depth that is included in the params of the stone). So, when you first communicate between nodes, you provide a public global stone, that is replicated, e.g. to a "public key server" analog or wherever. In the initial contact between any two nodes this global stone is challenged, and if successful any future communications between the two nodes works on a private stone (created also in the handshake). Then, each transaction - in the form of ibGib data structures - is proven in the future using that private keystone. The ibGib internal integrity allows for integrity of the data exchange, as it's basically hashing the entire communication for verification.
And so, identity is established among nodes, and all data is verifiable. It's very tricky to really try to "nail down" the provenance once you get multiple nodes involved, but even if there is a known mistake, that is where another aspect of the data comes into play: non-monotonic (append-only) data.
Again, this is like a version control repository for your data. This leaves a full audit trail, yada yada yada, it's really neat. I've typed enough for people to ignore anyway. If anyone is interested, ask about how this affects identity with users AND IoT devices AND AI! Ah well. At the very least, the website is instructional for navigating around merkle forests.
Key components of such an approach are:
1) strong consumer protection legislation that removes consequences from consumers - mainly, that if a transaction is disputed the lender can't report such transactions to credit rating agencies and the credit agencies can't use such transactions in the credit rating. In essence the dispute resolution is that if you claim that it's not you, then they can either drop the claim (and marking that claim on your credit rating would be libel) or press criminal charges on you for fraud, with the usual due process and level of evidence required.
2) A secure nationwide, centralized physical photo/biometric ID issued to everyone (which is a no-no in USA for political reasons), so that organizations who actually want to verify your identity have a reasonable means to do so in a manner that doesn't rely solely on "something you know". My brother knows all my personal information and would be able to impersonate me in any knowledge-based access; however, but passing an ID check would require either theft or forgery; he can't claim lost/stolen documents and get ID in my name since the face/prints/etc wouldn't match the ones on file.
The immediate effect is that it makes it easier for fraudsters to operate in the current environment that relies solely on knowledge-based authentication (since one can simply take a loan and deny it, and get away with it since the lender now has no way of proving who was it if they followed processes currently popular in USA) so the next-to-immediate effect is that all the organizations "offering trust" either face huge costs or switch their policies to handle identity verification in a reasonable manner. It will mean a temporary slowdown in issuing credit - that's not an inherently bad thing, but it does mean that such a change has to be timed to occur during an economic boom/bubble (where a temporary slowdown in credit is useful) and not during a slump.
So the problem is both that money isn't locked by a more secure scheme than lots of data AND it is a problem that businesses are allowed/able to accumulate massive data on people wind-up being negligent with it.
I think that there should be some kind of hardware key or smart card system issued by the government, where if you loose it or get it stolen, you can go to the post office or DMV or something to get the old key revoked and a new one reissued. The post office or DMV would verify your identity by biometrics or N other forms of ID.
Everything about you is a data point that could be copied.
Think more of some uncrackable government issued id card, that anybody that wasn't to hack it should go to the police station to get one.
Which you can only do after proving that you are who you say you are - which ultimately involves some (hackable) data.
If only most online authentication was that hard, and with so much risk for those attempting to fake it.
Even if showing up in front of US authorities was completely hackable, it'd still be better than the current state of affairs, because you'd have to hack people one at a time in person. (Unless you discovered some 0day in the key generation process or the hardware or something)
That naturally limits identity theft to a targeted attack on one individual, rather than being able to steal half of US adults identities all at once. Also, the hacker (or their accomplice) would only be able to hack one person per DMV (or Post Office) per month. And they'd have to at least vaguely fit your race, height, gender, etc.
A gang would maybe have the organizational skills to farm it out to a bunch of people. But, that's still limited to something on the order of thousands of people.
Let's not let the perfect be the enemy of the good.
Does it just come down to the cost of copying? Should all businesses who use identity data indemnify their customers against identity theft (as suggested elsewhere in this thread)?
Right now the "risk" has no cost - if you expose people's data there's not that much consequence besides bad PR. We should assign some dollar value to each person's identify leaked. That way, businesses can properly asses risk and reward when they start these types of projects
Overtime, I think businesses would rather avoid the liability of storing people's info in the first place
The problem has been for faaar to long that doing tech right takes much longer than the business side of the company is willing to wait for.
With the General Data Protection Regulation, any leak of private data caused by a major cybersecurity gap in a company will lead to severe financial sanctions such as a fine based on 4% of the company turnover.
This law will indeed give the risk a “cost” :).
The risk we need is to introduce is to make banks (not customers) responsible when banks allow themselves to be tricked w.r.t. personal identity. This would motivate them to come up with identity verification schemes reflecting ~anything at all that the security community has figured out in 50+ years.
Once CEOs know that they can go to prison if their customers' data is stolen, I assure you that they will suddenly become very interested in making sure their underlings follow best practices.
The "rework" to the system would be minimal if the impact of identity theft was a business' responsibility to handle. Businesses would reshape their processes based on the risk that they'd be willing to accept. Instead, we have a system that's broken, where individuals are punished for companies' (deliberate) incompetence.
Even worse. It's that businesses accept it and the individual bears some or all of the liabilities and hassles.
There's just no excuse for this to keep happening, but the processes meant to prevent this are clearly failing.
Windows tells you that using a password is probably a good idea for a user account. Many websites these days force you to use a combination of letters/numbers/special characters.
Why doesn't Amazon say "hey, this is publicly available, you wanna fix it?"
They do. It's clearly warned about in the interface both at the time you make it so and with a big "PUBLIC" sticker label afterwards. What's more, I've received warning emails from AWS notifying of (intentionally) public buckets.
Public buckets for private data are a deliberate and wilful choice by lazy, reckless administrators.
Making a bucket public should come with red flags, and there should be a simpler way for client-side code to securely access a bucket. If I save a user's uploaded files to the filesystem, I usually have to go out of my way to expose that. Even novices are less likely to put them inside the web root, so exposing such files involves jumping through hoops. Opening a bucket to the world is too easy in AWS.
Calling this situation "insecure defaults" was imprecise of me, my point was more that Amazon gives you a Big Red Button to "fix" things which has consequences like this.
I mean, there's a difference between being a novice and being stupid.
I find it funny how today there have to be red flags, warning signs and double confirmations everywhere. Are people less competent or are there simply lower requirements when hiring them?
I'm also not a devops person, so I'm definitely not debating in my wheelhouse here. It's just crazy to keep reading about a seemingly preventable problem that has the potential to do major damage in regards to data exposure.
A stressed engineer waiting for the rug to be pulled out from under him is capable of just about anything.
Also, amazon is improving their UX for these things already.
They probably didn't care, and should suffer consequences as a result.
This looks like a really small company who contracted this stuff out to a WordPress shop. There's almost no tech employees or positions on job boards for them.
This guy may have known exactly what he was doing, but relented to other higher ups who told him to do something. The shitty part is now this is public, all the execs can point to the developer and say it was his fault and fire him without incurring any repercussions themselves.
Now, if you don't know your S3 bucket is public that's entirely on you.
I'm as good at it as anyone I know (and unsurprisingly I work in tech) and it's still a complete crapshoot.
I know I've not enabled public access that I know of - but given the recent focus on this; what are the exact steps that I need to follow so I can sleep at night and show a level of diligence on the issue?
All companies processing the personal data of people residing in the EU regardless of the company’s location who have a breach of data where the organization has been shown to violate basic privacy design concepts can be fined 4% of annual global turnover or €20 million, whichever is greater.
It goes into enforcment in May 2018:
If Macie saves you just once from that giant fine it probably just paid for itself for years!
I haven't read the law but the faq does not mention the 20mil figure
https://www.eugdpr.org/key-changes.html
"Under GDPR organizations in breach of GDPR can be fined up to 4% of annual global turnover or €20 Million (whichever is greater). This is the maximum fine that can be imposed for the most serious infringements e.g.not having sufficient customer consent to process data or violating the core of Privacy by Design concepts."
So that 20mil or 4% (whichever is greater) is for companies that have seriously violated the GDPR. It remains to be seen how it is enforced, but my understanding is that this is purposely designed to be very punitive to force companies to have a dollar amount in mind when it comes to designing security and doing the right thing.
Amazon Trusted Advisor will automatically send you a weekly email if any of your buckets are misconfigured to allow public access. The catch is that this feature is only available if you pay for a premium support contract, which is hundreds or thousands of dollars per month.
If you have Trusted Advisor enabled but aren't paying for premium support, then you will still get the weekly email saying that there is a security vulnerability somewhere in your system, but when you click to see what it is you will just get prompted to hand over your credit card to signup for an annual support contract.
- Set up application with your AWS/S3 credentials
- Poll S3 to get list of all your buckets on a regular interval (once a day, every 5 minutes, whatever)
- Get a list of some files in those buckets
- Try to access those files directly w/ no authentication or authorization
- Set up some rules about how to interpret the results (look for any public files, look for specific private buckets, look any buckets that are public & haven't been whitelisted, whatever)
There's probably a ton of ways to do this. For simple use cases, it shouldn't be too tough. That'd be a fun hack for a day project, and I'd be happy to pair with you on it if interested. It's probably spending a little time looking around for an off the shelf solution first.
Your testing system would not help here at all, and if you spent the effort to make the system, you are already the type of person who isn’t going to turn the bucket public to make your life easier.
However, this is actually what CloudCoreo does - infrastructure security. More precisely, infrastructure security at deployment and continuous security monitoring (Evident only does the latter).
Disclaimer: I work for CloudCoreo.
Full disclosure- I work for UpGuard. I'm the same guy that found the exposed data set in that article.
Who will get to jail? Oh, nobody.
Who will get bonuses? Oh, the management.
Who will be fired? Oh, some programmers or admins.
The reason I say this is that knowing not to give a sensitive AWS S3 bucket public access is 101-level AWS expertise, which means either of these scenarios are likely:
- The persons responsible did not know any better, or
- They did know better, but made an error provoked by pressure due to understaffing.
Both of these point to a lack of competent security personnel, either due to understaffing, or hiring insufficiently experienced staff, both of these due to minimizing salary budgets (or clueless hiring managers, perhaps).