21–30 of 233 posts
I wonder how long it will take until another goal of these phone calls will be to gather enough samples to convincingly clone your voice.
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.
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.
Earlier quoted context omitted.
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.
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.
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.
I wonder how long it will take until another goal of these phone calls will be to gather enough samples to convincingly clone your voice.
There is already a variant where they try to get someone to say „yes“ and just use a recording of it to use as „proof“ that you agreed to some contract.
Yet another reason why phone number verification is the most insecure way to verify users and it doesn't matter if a company like Apple is using it or your bank using so called 'Military grade encryption'. The point still stands [4] with countless examples [0] [1] [2] [3]. Unless you want your users to be SIM swapped, there is no reason to use phone numbers for logins, verification and 2FA. [0] https://news.ycombinat…
I think we should start doing product liability lawsuits to any organization capable of having user financial data affected from their account, that is using SMS one time codes as either default, enabled by default, and the heaviest legal remedies to financial organizations where that's the only option we should also update PCI DSS compliance or whatever relevant security standard to call SMS one time codes totally i…
So... Apple Watch "quiet" is broken??
I’m still disappointed by Apples implementation of security keys. I want to be able to prevent all 2FA methods other than security keys, but it still seems possible in certain flows to authorise a new login with another iOS device making it vulnerable to this attack.
Earlier quoted context omitted.
This has nothing to do with SIM swapping or phone numbers.
TFA talks specifically about a victim buying a brand new phone, registering a new appleid, and getting MFA bombed immediately when putting in his old SIM...
I think it’s technically unrelated to the SIM, but rather to create the new Apple ID he used his existing (compromised, lol) phone number for “verification” or something. Which is weird in a way because then Apple must allow multiple accounts per phone number?