Breach affecting 1M was caught only after hacker maxed out target’s storage | Hacker News Reader

Breach affecting 1M was caught only after hacker maxed out target’s storage

arstechnica.com

102 pointsheshiebee32 comments

Given the fair assumption that any piece of data you give to a third party system that has access to the internet will eventually be breached, I feel like we need an entirely new system for data sharing.

The problem with most of these hacks isn't usually so much that the hacked system itself has lots of valuable data, but that the data from the hacked system can be used to hack into other systems that do have valuable data. Just like we tell people to only use a different password per-site, we need the option to essentially give only tokenized versions of our data to third parties. We've started somewhat with tokenization in place of credit card numbers, but we should be able to do this in many more areas.

There are obvious difficulties here regarding how we'd handle certain fields (e.g. how do I calculate your shipping if I don't know your exact zip code), but these should still be solvable problems.

The alternative of believing that every rinky dink (or non-rinky dink) site out there will be able to keep your data secure is laughable.

Absolutely! The same way we say you have to hash and salt passwords so they're not useful for cross-site breaches, it's even more important for any other piece of information that is used to verify identity. Especially since these other pieces of info aren't easily changed and can't be different on different sites. Or, facts about a person shouldn't be considered secret for the purpose of authentication, but that's hard when people have trouble with being asked to keep track of any new secret pieces of information they are given.

> There are obvious difficulties here regarding how we'd handle certain fields (e.g. how do I calculate your shipping if I don't know your exact zip code)

Forget calculating shipping; how do you ship me my product at all without me giving you my address?

(A quick napkin sketch would be that I wouldn't, I'd give you a USPS reference number, which you could use to calculate shipping costs as well as actually mail me a thing; only the USPS would be able to link the reference number to my physical location. There's almost certainly problems with this idea, which is why it's a napkin sketch.)

"USPS reference number" seems like it could work relatively similarly to a PO Box.

Main difference of course being that you want the ability to generate a unique "PO Box" per merchant.

Of course, there is a 3rd party (the post office in this case) that would need to know the mappings between real address and "reference number", but even in the case the post office got hacked at least they would only get your old mappings. Any new purchases would use new reference numbers.

You would also have to give the tax authorities the ability to lookup the reference number so they can calculate how much tax is owed. Taxes can very wildly even in the same zip code (some places are better than others about this).

This would be cool mixed with kind of a flipped free shipping thing, where I pay USPS $x a year and they deliver me up to y packages a week/year/whatever with no additional charge. You give the reference number to the vendor, the shipping comes up as free, they print a label and ship.

I like the idea, but even with a one-time code, the post office has a record of the reference number which could be linked back to the transaction.

Along with some form of digital cash analogue (i'm not sure existing crypto is it), we'd be getting close to restoring some privacy in online transactions.

Many people here will nod their heads along with you and then go back to their dayjob of warehousing as much personal data as they can get their paws on. Every time GDPR comes up the wailing and gnashing of teeth from HN is obnoxious, and yet every time there is a breach people are tutting.

These breaches are the personal fault of many of the people who frequent this site. As the FTC says - the first step here should have been not warehousing data they didn't need for their business purposes. Which is the mandate of GDPR as well.

Does the title bother anyone else? 1M what? People, records, a subsidiary of 3M.

"subsidiary of 3M" : made me laugh quietly.

"Customers" seems like a solid guess.

I’ve got a long running bet this is how AGI will be discovered as well. A full disk alert will lead a tired sysadmin to ssh into an old R&D GPU system and be greeted with “Hello, Dave”

plaintext passwords in 2019 .. it hurts to read articles like these.

These are often found in log files when people get a bit to log happy.

I've seen many smart developers accidentally log a request in an API that also happens to show the login credentials.

Even Google fell for that one recently.

Didn't Facebook fell for it too?

No. Never.

Could "Never" be defined as a time frame from year 2012 to at least 2019 ?

https://krebsonsecurity.com/2019/03/facebook-stored-hundreds...

https://www.theverge.com/2019/3/21/18275837/facebook-plain-t...

https://arstechnica.com/information-technology/2019/03/faceb...

https://www.wired.com/story/facebook-passwords-plaintext-cha...

This is true, but the way the article is worded it makes it very much sound like the passwords were being stored cleartext.

this is super common in my experience, along with checking creds into the repo

I swear - our 'single sign on' that requires a new login on every single system just trains people to put in their username/password without thought....

>full payment card numbers

storing these in plain text violates PCI-DSS

The article doesn't say that they were stored in plaintext. Still a PCI violation though!

From the FTC complaint:

"... stored consumers’ personal information, including consumers’ SSNs, payment card information (including full or partial credit card and debit card numbers, CVVs, and expiration dates), bank account information (including account and routing numbers), and authentication credentials such as user IDs and passwords, in clear, readable text on InfoTrax’s network."

And CVVs. Storing CVVs in any form breaks PCI.

Reminds me of something similar that happened to me once a long time ago.

I hacked into a server. I wanted to take a copy of everything so I made a tar of / to wget it to computer later. Only that the disk was at >50% usage so I filled it by making the tar file. Everything stopped to work with 0 bytes left of disk space (I wasn't root) so I kinda bricked the machine. I had to walk away in shame.

Don't feel bad. 1995. SunOS. Very patient boss. I did the same thing.

When I was learning Microsoft Access, many years ago, I didn't really understand joins. So I did a cross join with no where condition. And the machine (Windows XP) just sat there, and eventually locked up.

So I rebooted, and tried it again. Same result.

Eventually I figured it out.

> I had to walk away in shame.

No, you'd have walked away in shame if you had walked away in handcuffs. Don't do stupid stuff. Imnsho you got lucky that disk filled up before you could notch up a(nother?) crime.

What happened is arguably more stupid: by filling up the disk, 1) they definitely noticed, 2) I couldn't get what I wanted, and 3) I couldn't clean up the logs after it. Thankfully I had covered up my steps (or, more probably, the sysadmin was ashamed to see he had been hacked and chose to fix it and say nothing).

I hope you learned and not just to use 'df' more often.

It's unlikely you bricked the machine by filling the disk as a regular user. E.g. Ext2 by default reserves 5% for super-user processes.

Do something more useful with your time and skills.

Reply on news.ycombinator.com