Supporting multiple devices is a hard problem. We worked for a long time to enable it. Not Bitcoin protocol specific, but some words about our asymmetric key based multi-device solution here; https://www.mepin.com/lost-device/

The solution ^ still require a traditional account registration, or at least connection to the device that was used to create the account (if we go with passwordless registration). Otherwise, "must link their MePIN app to an actual user account in the target service" wouldn't be true.

Funnily; the reason to outsource is exactly about not putting all your eggs in the same shared basket. You outsource the 2nd factor and keep the first factor (passwords) in-house. Implementing everything in-house is a "same shared basket".

So you're dependent on a cloud startup for basic auth and you've got no more security than any other isolated two factor auth system.

Note that MePIN does not collect or need user's phone number, e-mail address or any other user information. You can use MePIN fully anonymously.

This is now fixed. Thanks for the kick.

First; the user does not have to care about OS, browser, ip address or location. Though those can be shown to a user if the service provider wants.

Authorization requests can only be initiated at the back-end by authorized service providers and only for users who have linked their MePIN app with that specific provider. Though of course login verification could be initiated with stolen username/password, which would then alert the user for verification.

Now the added benefit here is that with MePIN the user would immediately know that her username and password is at wrong hands if she receives a login verification request while not actually performing a login.

So obviously the user should not authorize unexpected requests. You would not authorize a login if you are not actually performing a login, etc. Concerned users can additionally set up a personal PIN code in the app.

Lack of good usability is currently hampering 2FA adoption, we are working hard to fix that.

In this model, all you have to do is time the authorization request appropriately. If an attacker can time their authorization at the same time that the user is logging in, a large number of users are simply going to authorize both requests thinking that it is some sort of glitch.

With the standard OTP model, a user physically can not enter their code for another user.

Unfortunately there are several cases where users have entered an OTP code for another user. The recent high profile case was with World of Warcraft's OTP.

The solution is based on Public Key Infrastructure (PKI). Each authorization must be signed with the user's private key. The app is managing and protecting the keys and certificates, so user does not have to figure out key/cert management. Some info here; https://www.mepin.com/technical-overview/

Working on it.

The service is distributed and hosted at 3 continents with 3 different hosting providers, so we take this seriously.

Other than that; You own your users and user database. No user data is stored at MePIN servers.

It's easier because you only need to tap the app to verify. No need for OTP codes, though OTP is a fallback if your device is offline.

So, users are locked into MePIN's proprietary app and depend on MePIN's website to log in, rather than using a open standard that can run offline. If you use HOTP/TOTP, you can use open source Google Authenticator, DuoSecurity, libpam, or any number of clients.

It's pretty easy to implement your own TOTP client if you don't like any of those. Here's a JS reference in 250 lines of code and HTML: https://code.google.com/p/google-authenticator/source/browse...

In MePIN's defense, DuoSecurity also has their own push notification for a single-tap login, so users are willing to trade interoperability for convenience.

Are you concerned that it is a lot easier to trick users into clicking a button to authorize the login?

Of course user behavior has to be considered. The MePIN app does allow the user to set up a personal PIN code, so an authorization would then require the PIN code and a tap.

A PIN would do nothing to keep a user from being tricked into authorizing an attacker's login.

Don't want to argue, but yes it would. It would stop the user for a second, giving time to the brain to process for a while what's going on.

If a user is willing to press the button, a PIN isn't going to stop them. Your app is decreasing security in favor of usability, which is not something look for when they are looking to implement two factor auth.

I think anyone who would blindly use your proprietary two factor solution that makes it easier for end users to authorize other people to log in would be silly.

I can use similar arguments; a user can be tricked to enter an OTP to a phishing site. For that the hacker does not need to time the attack to the same second, so it's much much easier attack for the hacker.

'No 2FA' is the real silly one here. Any 2FA is so much better than no 2FA, and usability has been a big issue so far in 2FA adoption.

This is the London I remember from early morning July 8th, 2005, the morning after the bombings. Was walking around to find a ride to the airport, couple of blocks from the double-decker wreck. Wish not to experience the same again.