Hacker News new | past | comments | ask | show | jobs | submit login
AT&T confirms data breach and resets customer passcodes (theverge.com)
60 points by Fizzadar 45 days ago | hide | past | favorite | 21 comments



> This FAQ says customers can set up free fraud alerts from credit bureaus Equifax, Experian, and TransUnion

I once subscribed to one of these and then was surprised by monthly charges a year or so later when the “free” bit ran out.


The credit freeze portion is permanently free for all 3 sites. I use it myself.

At the same time, these companies all offer other paid ‘monitoring services’ that they use heaps of dark patterns to push new users into paying for and confuse users to prevent people from finding the free ‘just security freeze’ service


They should be required to pitch into a state monitoring insurance fund as long as the social security number of person who's information leaked, hasnt rotated yet.

Seriously, what good does announcing 2 years of monitoring do, all it does is set a countdown to when somebody with the information knows to start using it.


Am I out of the loop, or is it really uncommon for a company to proactively reset passwords after a breach?

Maybe I'm being paranoid but after the whole T Mobile plaintext password fiasco a couple years back I worry that AT&T may have done something equally stupid, perhaps un-salted hashes if not plaintext passwords.

Edit: my bad, I didn't read this article first (and stupidly relied on another article I read earlier, which didn't have as much detail)... Does anyone have more detail on the new research? If the "passwords" are really short numeric pins, it sounds like they _are_ unsalted if they're so vulnerable.


Hashing is more or less pointless with such a small input space. Salts wouldn't help much.


if salt is a per-user randomly-generated 32 digit value, then even if you're using a weak, outdated algo like md5,

md5($ssn.$salt) is still safer than md5($ssn): pre-computed hash lookup tables don't exist for md5($ssn.$salt) but they do exist for md5($ssn).

A competent adversary could still crack these if they got the whole DB, but salting is meant to be a defense in depth thing, not a one stop solution to every database security problem.

Hell, if the adversary only gets the DB but not your application source code for some reason, them not knowing the order or formatting specifics of your salt and other static values might stop them from being able to crack even with the full contents of the DB - i.e. imagine your hashes are md5(md5(md5($ssn.$signUpTimestamp).$salt)."iejfmgklaihfje").

If the adversary doesn't get your source, there's almost no way they're guessing the hashes column is computed like shown above, they're just going to be banging their head against the keyboard trying to figure out why hashcat isn't spitting out passwords when they feed in the hashes and salts.

The idea of an adversary getting db access but not source access may sound strange, but I've been doing security work for close to two decades now and I've seen this happen multiple times to real companies.

Never undervalue defense in depth! You don't know what your adversary's capabilities will be so whenever you have an opportunity to deny them if they're missing a capability, you should try to if it's not an unacceptable businesses decision.

Disclaimer: you should NOT be using MD5 for security-sensitive one-way hashing in 2024. bcrypt is a much stronger algorithm and has stood the test of time well, Argon2id is newer so less battle-tested, but is ostensibly a major improvement even over algos like bcrypt.


As soon as you've lost the db, with low-entropy inputs like these, you should assume that the plaintext has been compromised and should treat it as such, especially if your "security" corresponds to under a billion hash computations. It doesn't count as "Defense in depth" when the layer is as thin as tissue paper.

If you actually do care (and you still don't really want to), there is actually a regimented way to do this instead of the ad-hoc nonsense that you propose. Add a service-specific salt embedded in an HSM; this is sometimes known as a "pepper". You still would probably consider resetting everybody even in this case if you lost the DB, though.


I'm not asserting that what I've proposed is all that should be done, and my post was not meant to be exhaustive, just offering some extra DiD tips when it comes to hashing, salting. My suggestions are to mitigate the impact of precomputed lookup tables, forcing adversaries to crack the hashes themselves, and offering defenders a slight information advantage in circumstances where an adversary gets access to a database, but not source code, which really isn't that obscure or unusual of a situation.


these aren't login passwords like as part of a credential set. these are what AT&T does, in fact, refer to as "passcodes." and an account holder (or any agent of such) is required to furnish it to any AT&T representative in order to discuss and/or access sensitive account information.

kinda like MFA before MFA became ubiquitious. i have been required to provide all three—credentials, TOTP, and passcode—to access my account for as far back as i can recall.


These large companies have become so complacent. Their handling of user data is comical, at best.

“SOX” compliance and other certifications are just buzzwords at this point.


SOX compliance is not about data security though. It's about making sure financial fraud isn't happening.

There isn't really a cybersecurity law or framework with the teeth of SOX or as widely and thoroughly implemented. Maybe if there was they'd be more valuable.


Really think we are due for the black swan event of user data — payment info, explicit personal photos, private conversations, etc. The average person just has way too much implicit trust in these large corporations who for the most part do not take their privacy obligations seriously.


A reminder for anyone who hasn’t already done it, freeze your credit at all 3 credit agencies. Only unfreeze the 1 you need for the time period it needs to be unfrozen for, if applying for new credit. This should stop most identity theft related to the SSN leak.

This should be standard practice for everyone after the Equifax breach several years ago.

Of course if someone can take control of a person’s phone number, that’s essentially a new form of identity theft now that 2FA has turned our phones into our identity, whether we asked for it or not.


Freezing only the 3 major credit reporting agencies may not protect you from e.g., a bank account being opened in your name.

There are _many_ consumer reporting agencies in the US:

https://www.consumerlawfirm.com/credit-reporting-agencies.ht...

Many in the list, at the link above, are not a concern for financial fraud in your name. But, you might want to expand your list of companies you freeze your report with by a few more to gain some safety. My personal minimum list:

  ChexSystems (used by many banks before opening new accounts)
  Equifax 
  Experian 
  Innovis (sometimes referred to as the 4th major credit reporting agency)
  LexisNexis (LexisNexis acquired SageStream; same services/types of customers as big 3)
  Transunion


Seconding this. It's free to create accounts at the 3 agencies (Equifax, TransUnion, and Experian) and place an indefinite freeze until you need to apply for credit in the future.

Sometimes people sit on the data in these breaches for years before using it, after the dust has settled, assuming people have since let their guard down.

Unfortunately, it's also worth noting that you typically opt into allowing these agencies to sell your data during signup, so after be sure to comb through the privacy policies for opt-out links and submit requests to prevent the agencies from sharing your data with third parties for marketing offers, etc.


Completely agree with your comments.

Getting a prepaid burner phone or second SIM for 2FA _only_ isn't the worst idea. I've also used pretty locked off Google voice, but not all companies accept a VOIP number.


I have several credit cards that offer complementary credit monitoring on a monthly basis and already have alerts setup from credit karma and credit sesame.

In my experience, I always get prompt updates on changes to my credit (ie, new hard inquiries when I was mortgage shopping). Usually less than an hour after the actual event. In some cases, it’s instantaneous.

Freezing credit is more of a nuclear option in my opinion. Unfreezing your credit with these agencies is not something that is easy. Usually takes a couple of days.

The one aspect I have “frozen” access to is my “Work Number” by Equifax. Apparently companies have been sending Equifax this information without our explicit consent. It’s disgusting.

https://theworknumber.com/


Prevention is better than trying to cleanup after a mess that’s already been made.

Unfreezing has been quick and painless. I just need to ask whoever is doing the pull which agency they’re using. It does not take days. A credit check should also be a pretty infrequent event. I froze mine back in 2017 and have only had to unfreeze it a handful of times in the last 7 years.


> Freezing credit is more of a nuclear option in my opinion. Unfreezing your credit with these agencies is not something that is easy. Usually takes a couple of days.

Please don’t spread FUD. It’s instantaneous if done online, have done it several times.


Unfreezing can be done instantly online for all of the agencies, the same way you freeze it.


> says that leaked information "may have included full name, email address, mailing address, phone number, social security number, date of birth, AT&T account number and passcode."

I fully agree with all the other comments out there which say that companies don't take privacy seriously enough and that there aren't enough real penalties when this data is leaked.

That said, are we ever going to stop pretending that this data is "private" anymore? That is, I'm pretty sure that everyone who has ever held a digital account has had their name, phone, email, address, and more importantly birthdate and SSN leaked numerous times already. They're simply no longer private as a matter of fact. But this set of data is essentially all that is required in most places to, say, open a bank account and pass KYC restrictions. Why? Why are we still pretending that this information isn't available on pretty much everyone to pretty much anyone that has smallest amount of technical knowledge?

I agree with the other comment about always freezing your credit scores, which makes it much more difficult for others to fraudulently open accounts in your name. Also note the entire financial system knows this, but they know that most of the cost is born by the victim (it's been repeated a million times how "identity theft" is essentially a made up term banks came up with for shifting the blame onto the victim instead of themselves for not having good identity verification procedures in the first place), which is why they don't recommend it by default and more broadly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: