Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SoundCloud Data Breach Now on HaveIBeenPwned

haveibeenpwned.com

Post reply on HN
Print view View original

91–100 of 113 posts

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#91

Post by karlgkk »

thinker1972 wrote: post #86

People should be using email alias. 1 unique alias per 1 uniques service and websites for proper segregation. If any of the unique alias leaked or getting spammed you'd know where the source is and blocking that specific alias would limit the breach. Theres simplelogin.io, addy.io, firefox relay, apple hide-my-email, custom domain catchall etc for that.

IMO use email providers that have that built in. Because if your alias provider goes down, you’re fucked. And considering it’s a much less stable business than an email provider, it’s more likely.

If Gmail goes down in 20 years, it will be a major occurrence. If mailgoforward.fart goes down, you’re screwed.

The advice is, as always, use a second mail address for “sensitive” providers. Use a password manager and two factor for everything. Ideally one that integrates into your phone and browser.

For traceability, most providers support a + alias syntax now. Ie foobar+baxservice@provider.com

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#92

Post by goblin89 »

LoganDark wrote: post #76
storystarling wrote: post #66

Earlier quoted context omitted.

This sounds like a classic consistency vs latency trade-off. Enforcing strict quotas across distributed services usually requires coordination that kills performance. They likely rely on asynchronous counters that drift, meaning the frontend check passes but the backend reconciliation fails later. It is surprisingly hard to solve this without making the uploader feel sluggish.

That would explain why the front-end would allow you to attempt something that goes over your limits, but not why the back-end would reject something that doesn't go over your limits.

My bet at the time was that they have a bunch of hidden extra limits based on account age, IP/user agent information, etc. If that is true, their problem is that they advertise the larger limits instead of the smaller limits (to get more users signed up), and that they do not communicate when their extra limits apply and instead straight up upsell you, which are both dark patterns.

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#93

Post by perching_aix »

karlgkk wrote: post #91
thinker1972 wrote: post #86

People should be using email alias. 1 unique alias per 1 uniques service and websites for proper segregation. If any of the unique alias leaked or getting spammed you'd know where the source is and blocking that specific alias would limit the breach. Theres simplelogin.io, addy.io, firefox relay, apple hide-my-email, custom domain catchall etc for that.

IMO use email providers that have that built in. Because if your alias provider goes down, you’re fucked. And considering it’s a much less stable business than an email provider, it’s more likely. If Gmail goes down in 20 years, it will be a major occurrence. If mailgoforward.fart goes down, you’re screwed. The advice is, as always, use a second mail address for “sensitive” providers. Use a password manager and two f…

I don't get why + addresses always come up in this. They're machine-undoable by design.

Using randomized relay addresses instead gives you an immensely higher confidence that when a given contact address starts getting spam, it is misuse stemming from a specific entity. Especially if you rotate it at a fixed time interval, cause then you can even establish a starting timeframe.

Still not perfect but it can never really be, and not even out of email's fault. As long as DNS and IP addressing rule the world, there's only so much one can do. Once identity is private-default, it becomes a secret handling problem at its core, a capability these schemes were never designed to provide.

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#94

Post by thinker1972 »

karlgkk wrote: post #91
thinker1972 wrote: post #86

People should be using email alias. 1 unique alias per 1 uniques service and websites for proper segregation. If any of the unique alias leaked or getting spammed you'd know where the source is and blocking that specific alias would limit the breach. Theres simplelogin.io, addy.io, firefox relay, apple hide-my-email, custom domain catchall etc for that.

IMO use email providers that have that built in. Because if your alias provider goes down, you’re fucked. And considering it’s a much less stable business than an email provider, it’s more likely. If Gmail goes down in 20 years, it will be a major occurrence. If mailgoforward.fart goes down, you’re screwed. The advice is, as always, use a second mail address for “sensitive” providers. Use a password manager and two f…

I'd say for longevity and portability use own custom domain. Simplelogin, addy support using own custom domain. Its just $10-15 something per year. Most tld allowed max cumulative renewal up to 10 years so $100-150. Setup a yearly calendar reminder on January to renew +1 year so at any give time the domain will have minimum 9-10 years before expiring. If got hit by a bus tomorrow then 9 years should be long enough time for whatever accounts linked to the domain to rot and be useless for the next domain owner.

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#96

Post by storystarling »

LoganDark wrote: post #76
storystarling wrote: post #66

Earlier quoted context omitted.

This sounds like a classic consistency vs latency trade-off. Enforcing strict quotas across distributed services usually requires coordination that kills performance. They likely rely on asynchronous counters that drift, meaning the frontend check passes but the backend reconciliation fails later. It is surprisingly hard to solve this without making the uploader feel sluggish.

That would explain why the front-end would allow you to attempt something that goes over your limits, but not why the back-end would reject something that doesn't go over your limits.

Fair point. I suspect it comes down to how they handle retries. If an upload times out but the counter already incremented, the system sees the space as used until an async cleanup job runs. It is really common to have ghost usage in eventually consistent systems.

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#97

Post by direwolf20 »

poglet wrote: post #78
direwolf20 wrote: post #72

An email–only breach seems to cheapen the value of HIBP. It's not telling me if my password was leaked.

Plus, the "Recommended Actions" only show me two sponsored products (1Password and Truyu) leaving me confused in what I'm supposed to do now.

It's just advertising slop like any other now. No different from "your computer has a virus, buy our cleaner app"

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#98

Post by storystarling »

LoganDark wrote: post #76
storystarling wrote: post #66

Earlier quoted context omitted.

This sounds like a classic consistency vs latency trade-off. Enforcing strict quotas across distributed services usually requires coordination that kills performance. They likely rely on asynchronous counters that drift, meaning the frontend check passes but the backend reconciliation fails later. It is surprisingly hard to solve this without making the uploader feel sluggish.

That would explain why the front-end would allow you to attempt something that goes over your limits, but not why the back-end would reject something that doesn't go over your limits.

Fair point. I suspect it comes down to ghost reservations or stale caches. If a previous upload failed mid-flight but didn't roll back the quota reservation immediately, the backend thinks you're over the limit until a TTL expires. Or you delete something to free up space, but the decrement hasn't propagated to the replica checking your quota yet.

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#99

Post by storystarling »

goblin89 wrote: post #92
LoganDark wrote: post #76

Earlier quoted context omitted.

That would explain why the front-end would allow you to attempt something that goes over your limits, but not why the back-end would reject something that doesn't go over your limits.

My bet at the time was that they have a bunch of hidden extra limits based on account age, IP/user agent information, etc. If that is true, their problem is that they advertise the larger limits instead of the smaller limits (to get more users signed up), and that they do not communicate when their extra limits apply and instead straight up upsell you, which are both dark patterns.

That sounds plausible. I've had to implement similar reputation-based limits on my own backend just to keep inference costs from exploding, so I sympathize with the fraud prevention angle. Masking that as a generic quota issue to push an upsell is pretty hostile though.

Re: SoundCloud Data Breach Now on HaveIBeenPwned

#100

Post by varispeed »

thinker1972 wrote: post #86

People should be using email alias. 1 unique alias per 1 uniques service and websites for proper segregation. If any of the unique alias leaked or getting spammed you'd know where the source is and blocking that specific alias would limit the breach. Theres simplelogin.io, addy.io, firefox relay, apple hide-my-email, custom domain catchall etc for that.

Many websites block such providers because of spam.
Post reply on HN