[iafan]

This is a very interesting concept. I'm pretty sensitive to UX issues, and I'm yet to see nicely implemented and secure auth flows. All non-OS-native 2FA solutions (Google Auth, Duo) seem a bit cumbersome (and require additional efforts to implement and to setup for the average user). Apple does auth right with their Touch ID (both for logging in and to confirm transactions). I see a potential for SecureLogin to be as close to that Touch ID user experience as possible.

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.

[lobster_johnson]

The enterprise version of Duo apparently works by having the mobile app wake up to ask you for confirmation for the login -- similar to how Apple's Touch ID automatically opens to confirm things like Apple Pay if you initiate from the desktop -- rather than making the user open the app, select the account and generating a number.

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.

[iafan]

Yeah, I'm an every-day-user of enterprise Duo app. It is as good as a third-party app can be (on iOS specifically), yet you have to do extra steps as compared to Touch ID alone: force-press the notification, click Accept, then confirm with Touch ID. The first steps out of two are just a limitation of how apps work in iOS. If your phone is in sleep mode, you will miss the notification as well. Such things really need to be implemented on OS level.

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.

[bastijn]

Blizzard 2FA doesn't even come up. Having it installed is good enough for automatic detection if on same device if I remember correctly. If on different devices you have to press accept or deny comparing a unique code on the app vs. On the app where you want to login. Much easier than copying the code.

[pbarnes_1]

Google has this option in the Google iOS app (and presumably the Android one).

Interactive Brokers have had something like this for a couple of years.

[homakov]

Happy to hear back from like minded person.

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.

[iafan]

> 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.

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?

[homakov]

Please email [e-mail]

I can continue about extensions there

[Ajedi32]

1. This is a good point. I wonder if it might be better for the initial adoption period to build this protocol into a password manager (preferably several existing popular password managers), then market it as something sites can implement to improve UX and security for users who use password managers. (E.g. Instead of having your password manager generate a password for you when signing up, you can just click one button on the signup form and the protocol will handle everything for you. And it's more secure since the site only stores a public key instead of a password.)

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.