[olemartinorg]

I'm intrigued! But a few questions/comments:

* How is this two-factor? I only see one factor (a thing you have, your phone). Email adresses are not secret.

* Again, email adresses are not secret. How do you limit login-spamming? I don't want to wake up in the middle of the night because someone is trying to break into my account.

* What about timing attacks? If i stand over your shoulder while you're in the library - and i try to log in using your email address a few seconds before/after you, wouldn't you think "oh, probably a fluke" and allow my login? How would you differentiate between logins?

* If you're not that security-minded, you could have a desktop client as well - so you don't have to rely on your phone. At that point you could probably just have a browser plugin that does it all for you. (And at this point you're pretty close to what i already do with LastPass, although the site i'm visiting doesn't have to do anything special other that implementing a regular username/password login system.)

EDIT: Also, as far as i can see from the Play Store screenshots, the app only asks you "Do you want to log in at <site>?". A far better solution would be to show the user a number sequence (or a cute cat or dog picture) on both the login page and the phone. If those two mismatch, the login attempt is not from your session.

[arethuza]

So two factor would be "something you know" (password) and "something you have" (phone) - and this just has the latter. So it's single factor but with a different single factor than the passwords we are all used to.

[Caprinicus]

Well then I'd rather just have a password

[EGreg]

I have a question too. How do you avoid being spammed by someone creating a new account with your email or sending "forgot password" over and over?

[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)

[snupa]

* Once you create an application, you can set how you want your users to provide their identity. You can ask just for the email, email+digits or just their phone number. However, when you deny a notification from your phone, the user is required to provide the second identifier (email requires additional last 3 digits, phone number also requires email, and email+digits requires the full number in addition) * The system only allows a single login per user, so if you have initiated the request first, somebody else would have to wait for you to finish the request until they can initiate it). There are additional limitations happening in the background that prevents spammy logins to reach the user's phone. * We're still trying to improve our UX, so we might take that in consideration for future releases

[olemartinorg]

* So if i deny the login attempt on my phone, an attacker who knows my phone number can still log in to my account? Email + phone number is not two factors, it's zero (neither is a secret).

* So what if the attacker started a login request a few milliseconds before i did? How can i differentiate between the attackers login attempt and mine?

[philsnow]

> The system only allows a single login per user, so if you have initiated the request first, somebody else would have to wait for you to finish the request until they can initiate it

sounds like an easy DoS vector if the person knows your phone number as well