Hacker News Reader

Comment by Zetobal | Hacker News Reader

Same problem with Instagram it's insane that so many giant companies have no rate limits in their recovery flows.

The problem with adding rate limits, at least a global per user rate limit, is that you then create a new denial of service issue, preventing people from being able to recover their account.

Why? You can rate limit the business logic but still show the user the default flow.

For example: if a user is requesting a reset password link 10 times a minute you can just send the link one time but display everytime that a reset link was sent by email.

This flow is a bit different from a password reset email, it's a notification with a direct call to action, allow or deny.

You can't debounce them like you can with a reset password email flow.

With a typical password reset email, the actual password resetting is done by the user after they click the link in the email, only someone with access to the email can proceed, and they can only proceed on the same device that they clicked the email link.

In this flow, there is no further on-device interaction.

Rate limiting per user is mostly a thing of the past. You set other rate limits and various rules and then get the rate limit per user for free.

> Rate limiting per user is mostly a thing of the past

Someone please tell this to fidelity. After 3 wrong password attempts they lock your account.

Fidelity are clowns. They've spent an impressive effort breaking every god damn third party integration AND using Akamai to block scraping. I can scrape Ameriprise fine, but no matter how creative I get Fidelity gives back a weird error on login.

(This is on top of them not sending any actionable email when changing my contributions to 0 in between pay periods)

I'm rolling my 401k out as often and fast as possible. I hate American banks so much.

> us[e] Akamai to block scraping

Would https://github.com/lwthiker/curl-impersonate help? Haven’t tried with Akamai, but did help with another widely used CDN that shall remain unnamed (but has successfully infused me with burning hate for their products after a couple of years’ worth of using an always-on VPN to bypass Internet censorship and/or a slightly unusual browser).

I'm using this to fill forms interactively and emulate a user. https://github.com/rust-headless-chrome/rust-headless-chrome

Afaict, it drives a stock Chromium instance. I'm not sure how Fidelity is detecting it, but they detect it even in normal headful mode. Idk if there's some JS that notices there's no mouse-move movements.

It's just not worth the headache. I despise bending over backwards for companies like this. But obviously I have no choice since they're my 401k plan facilitator.

> Fidelity are clowns. They've spent an impressive effort breaking every god damn third party integration AND using Akamai to block scraping.

What’s funny/sad is they probably pat themselves on their back thinking their security is so advanced and awesome. Financial services web integrations are all total clown shows.

but can't you buy API access? I would assume that's more of a business decision to promote paid for API access, rather than "security" against scraping.

And they convert usernames to sets of digits so they can be entered more easily on phones. Naturally this results in a lot of collisions.

If you’re getting DOSed by identical prompts you already can’t recover your account since you’ll likely hit the wrong prompt. There’s no protection here against an MFA fatigue attack attempt.

it wouldn't be hard to add to the app though. obviously if you get a flood it's bullshit and more than a couple can be ignored. It's not rocket surgery

You're telling me Facebook, with its billions of dollars and leetcode interviews, can't figure this out? That is outside the realm of computable functions?

Reply on news.ycombinator.com