I don't know what protocol is used, and I've never tried it, because it's not part of the single-user Duo Mobile app.
But this always struck me as a much more user-friendly way of doing 2FA than the Google Authenticator style that generates numbers that you then have to manually enter.
But apart from arguably good iOS app UI, it takes the whole IT department to enable Duo 2FA and educate employees on how to enable and use it on their personal accounts, and that's what I don't like about Duo and other solutions. Also, this is just a second step of the two-factor auth, which means the first step (usually plain old username/password auth) is still there.
In my ideal world, I'd prefer something that worked out of the box (with very easy bootstrapping process). I believe SecureLogin, as a concept, has potential here, and if implemented right, might lead to some standardization and implementation of more transparent 1FA/2FA flows.
Interactive Brokers have had something like this for a couple of years.
1. I myself hate native apps, but the catch is web apps are 100% depended on the servers behind them. So I would be responsible for JS I serve any single request. Otherwise, Web version is fine.
Lots of catch 22. I would definitely through $10k+ on a polished UX + native app, if someone with large userbase can commit to using it. I already gave this project a TON of my time.
2. I hate that 50MB size of electron apps too. Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.
3. Actually there's amazing self-discovery iframe - https://securelogin.pw/s when in iframe it will parent.postMessage if you have a native app. But Safari does not support 3rd party iframes...
You think showing app links on the same screen is better? Good idea
4. Will improve the demo app
That's what profiles are for. If you want another identity: create another profile. It is possible to keep unlinked accounts under the same SecureLogin profile, BUT we end up with all websites asking for your E-Mail (like they need it for some reason) so that's why it is sent by default.
Real privacy is hard, it's not just different email. It's different browsing context and sometimes even VM. That's why I do not pursue paranoid level privacy, and just offer Profiles.
Happy to hear more.
I believe that it'd better be explicit (like in OAuth, where the web service asks for a permission to access your email) and optional (defaulting to not asking for email).
Note that services usually don't need emails (at least not right away). They should also continue working just fine if the user decides not to provide their email initially — the service may ask for user's email at a later step. I also see that the similar concept might be used to ask people for or other sensitive data, like delivery/billing address and payment info; this way I as a service developer don't have to store anything on the web service at all except for the unique user token, and the user would be able to provide this information with a single click as well — same as in your demo app where the user confirms a transaction.
> Browser extension does have same problem as a website though. That's neither more secure nor more fast derivation, so that idea was dropped first.
I'd probably disagree here. Installing an extension is much faster/easier than a native app; it can store data in localStorage (so no centralized service is needed), it can solve your Safari-related discoverability issues, and it can provide a really nice UX for web-based service authentication with no context switching between apps. I'm not a security expert, but a browser extension storing your data locally should — theoretically — be as secure as a native app. Am I missing something here?
Would love to continue the discussion offline. Is it ok to email you?
I can continue about extensions there
Then once it gains sufficient adoption, sites would be able to slowly start phasing out the use of passwords by making the use of SecureLogin mandatory.
While I see the potential, I understand that this is an initial implementation, so it has UX issues:
1. First and foremost, the user has to download an app in order to sign into your service. That's a huge ask. Service providers will be hesitant to implement this, since this will mean losing customers. The implementation has to be really polished for this to gain traction, IMO. Without getting initial traction, it's less likely that this can be implemented natively in browsers/OS, where this technology makes more sense and can have better UX. Kind of a catch 22.
2. Related to 1: A 50+MB Electron app is definitely not a casual download. It has to be as lightweight and OS-native as possible. For most likely use case (web app authentication), did you consider using browser extension that would store the data locally? Might be a good alternative to a downloadable app at least for that common use case.
3. When signing in, it asks if one has the app installed. I don't want to be asked. If the app is not there, I want to have it installed in one click, and then have the auth retried. And visiting a separate https://securelogin.pw/ site for downloads is not the best option as well. This bootstrapping process is very important. Again, a browser extension might help with this, since it can communicate with the page and make itself discoverable.
4. As I understand, Cobased is your reference demo app. As such, it needs more polishing/explanation (read: some narrative in addition to the UI).
---
And a non UX-related question: nowadays people not only value security, but anonymity as well. Does SecureLogin have to pass profile email address back to the app? Can the protocol work in the way that simply uniquely identifies the user for the target service via providing some service-unique token but not disclosing an email address? In other words, the protocol might benefit from the fact that no one can link account on service A to the account on service B.