Live data from Hacker News

Ask HN: Mobile devs who added Apple Sign In, what conversion changes?

news.ycombinator.com

71–73 of 73 posts

Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?

#71

Earlier quoted context omitted.

Most people are already vulnerable to this because they use the same password everywhere. The fewer service providers there are holding a copy, the lower the risk of compromise.

This is not how it works. We don't hold any copies of users' passwords these days, there are hashes for that. Certainly, some old, or poor quality in-house software still do it, but then it won't offer you integration with whatever SSO service anyway. And single point of failure is very real, if you trying to operate world-wide: sign-in with X may suddenly become illegal, or inaccessible outside of the USA.

Like Yahoo?

It keeps happening, and all it takes is one of the places you've used the password to lose it.

Generally "sign in with X" still provides an email recovery option.

Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?

#72
post #70

Earlier quoted context omitted.

Interesting. Wouldn’t that allow someone to sign up for service Y with an email address associated with an account in your system using service X, in order to get access to the account in your system? Maybe there’s something I’m not seeing, but it seems dangerous to rely on the identity provider’s email address to authenticate the user.

Your local account is associated with X, you attempt to sign in with Y, the Y authentication was successful but there is no local account associated with Y. Some heuristics (such as email address matching) means you indicate to the user that perhaps they meant to try X? They sign in with X, and now you have authentications from X as well as Y for the user. You use the authentication from X to authenticate, and you as…

Exactly this.

Re: Ask HN: Mobile devs who added Apple Sign In, what conversion changes?

#73

I hate technologies like this. Not because I don't think they at least contribute some benefit to end users. I see it as oblivious executives trying to monopolize whatever they think they can monopolize. The future is in yubikey-style authentication.

Yubikey-style is dead in the water since you can't back them up or exfiltrate the key. It will never appeal to more than a handful of users willing to jump through those hoops. Just needing to have every hardware key on hand to register with each new service is so bad I thought I was misunderstanding the UI. I never used them again. The hoops might be worth it for a critical service that holds your $millions. But har…

yubikey-style. I think it's about the concept, not a specific implementation.

It's orders of magnitude more secure to have a device that holds a key rather than depending on (a) website to support a particular authentication platform and (b) me having credentials for said platform.

I agree, not having direct unfettered access to the keys is a flaw in current implementations. Also I don't see the steps a person needs to go through or GUI intuitiveness as things that will prevent this kind of technology from becoming ubiquitous. I'm confident adoption will reach terminal velocity. Just not sure when it'll happen. I think it won't have a chance, though, until all the right standards are in place.

Post reply on HN