[olemartinorg]

Good point, you don't. But on the other hand, filtering out an email you don't want is easy (in most email clients), so you won't get a notification each time. I'm assuming this app has no filtering, so if someone wanted to DOS me with this, they could - there's no way i could (or would) handle a ton of login requests per second to try to find the login request i initiated. You can't DOS someone with account signups or the "forgot password" functionality, as they could still log in to whatever service they need (while their mailbox fills up).

[snupa]

The app actually has a firewall, preventing DOS attacks on the user. The main rule is that only one authentication request can be active per user, so the user will always receive ONE push request at a time. Also, when you create an app, you can specify the number of authentication requests you expect, coming from your app. You can (currently) set it from 1 to 25 requests / second. So if somebody would try and DOS you, UNLOQ will limit and filter these requests.

[arianvanp]

But i still wouldnt know which request was genuine. Even worse. The genuine request might be filtered out! By doing this you make the DoS more effective actually.

[EGreg]

I have never found a good solution to the trade-off of protection against brute-force vs availability.

If I disallow X requests per second then I might enable DOS attacks on a user.

What if a cluster of zombie machines around the world is attempting to log in as a politician to gmail at their publicly known address? How would the politician ever get in, if login attempts are rate limited?

[anaolykarpov]

the rate limit can be per username/per ip address/per time period (you receive one notification once every 10 minutes), or a combination. Yes, when you have a botnet of a few thousands computers you could DoS someone. But with that in hand you can also DoS every web service on the internet (with a few exceptions)

[EGreg]

But sometimes DoSing an individual is more effective