Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't use third party auth to sign in

gurjeet.singh.im

Post reply on HN
Print view View original

501–510 of 544 posts

Re: Don't use third party auth to sign in

#501

Post by fiddlerwoaroof »

voiper1 wrote: post #418
fiddlerwoaroof wrote: post #413

Many sites seem to use the email associated with the third party account as the identifier: so, if I lose access to Google, I can use the email address to reset the password or use Facebook or Apple sign-in, as long as those accounts serve up the same e-mail address.

My sign in as google uses the @gmail address, which I don't have access to other than signing into google, so I wouldn't be able to get the reset email link. Interestingly, since I use my own domains, my facebook signin is different than my gmail address. But interesting, I've never tried using a second oauth as a match to the first.

I know this is how discourse handles federated identity: it uses the Oauth2 server to match the account's email address against the Facebook/Google/Twitter account's stored email address. Spotify works this way too.

Re: Don't use third party auth to sign in

#502

Post by Shorn »

spians wrote: post #116
grezql wrote: post #6

Has anyone else noticed random popups on 3rd party websites asking for google sign in? I even used firefox when it happened: https://imgur.com/a/JC52lBV (lequipe.fr) https://imgur.com/a/VSM3Uk9 (reddit.com) https://imgur.com/a/KpVCYBL (medium.com)

You can disable these annoying prompts by going to https://myaccount.google.com/permissions and disabling "Google Account sign-in prompts". Ideally it should have been user opt in but Google followed dark pattern here.

Hey, thanks for that.

Just confirmed this does seem to stop the annoying login popups from Medium, etc.

I tried to figure out how to disable that a few months ago but my google-fu was weak and it seemed like nobody knew how to do it.

Re: Don't use third party auth to sign in

#503

Post by StavrosK »

u801e wrote: post #497
ukoki wrote: post #5

To add to this: Never use a @gmail.com address, buy your own domain and pay the $6/mo to get a Google GSuite with your name@fullname.com address instead. If Google locks your account, you can now move your email hosting to another provider and won't lose access to your entire digital world. Be aware that doing this now means your DNS provider and domain registrar become vectors for hackers to take over your email acc…

> app-based, not SMS-based two-factor authentication) How does that work when using an email client and connecting to the server and using SMTP and IMAP?

You generate one password per client (i.e. app-based).

Re: Don't use third party auth to sign in

#504

Post by sedatk »

anderslemke wrote: post #305
sedatk wrote: post #293

Earlier quoted context omitted.

> which proves that this is possible. How does it prove that?

I've built Promise, to prove (to myself at least), that it would be technically possible to build authentication infrastructure, that can be used across sites, without having to store any data unencrypted, and furthermore, not storing any personal data at all. And it works. It's a bold choice of words, I acknowledge that. And the proof is only as strong as my abilities to write software. This is yet another reason wh…

I understand, but don't you still have the capability to ban a domain/user? How is it different than Google in the context of the post?

Re: Don't use third party auth to sign in

#505

Post by u801e »

StavrosK wrote: post #503
u801e wrote: post #497

Earlier quoted context omitted.

> app-based, not SMS-based two-factor authentication) How does that work when using an email client and connecting to the server and using SMTP and IMAP?

You generate one password per client (i.e. app-based).

How does the client identify itself during the SMTP or IMAP transaction?

Re: Don't use third party auth to sign in

#506

Post by StavrosK »

u801e wrote: post #505
StavrosK wrote: post #503

Earlier quoted context omitted.

You generate one password per client (i.e. app-based).

How does the client identify itself during the SMTP or IMAP transaction?

It uses the password that you generated for it. I don't understand where the confusion is.

Re: Don't use third party auth to sign in

#507

Post by bsder »

TedDoesntTalk wrote: post #471
Osiris wrote: post #466

Earlier quoted context omitted.

I work in crypto and we sell a hardware device to keep your seed phrase secure and the physical device is required to sign transactions. But then you should listen to the advice we're given if we use one for personal use. 1. buy two devices 2. Generate a phrase on one then import to the other 3. Put the second one in a safety deposit box in another city or state, or a safe with a family member also out of the city or…

> [effective and meaningful] Security is hard. We should build systems that make it easy These are in direct conflict with each other.

Not necessarily.

What's your threat?

Most people are not trying to stop a determined attacker. Most people just want random people to not get be able to get into their stuff--same as a physical lock.

They carry a physical key on their person. It's not too much to ask them to carry a "digital" key on their key ring.

The problem is that most "digital" keys are a pain in the ass:

1) Mostly because everybody wants to "centralize" authentication so that they can charge you and administrate you.

2) Secondarily because there is no good solution for talking to the key on your person. NFC sucks. USB requires that I plug my key in. WiFi requires that the device be able to hit your network. BLE has no access from web pages.

BLE is probably the best choice, but there is no real money in making it work.

Re: Don't use third party auth to sign in

#508

Post by bsder »

ryandrake wrote: post #363
snorremd wrote: post #98

Earlier quoted context omitted.

Fastmail is very good. The web client is pretty simple, but feels so darned responsive (as in fast) compared to what I was used to from GMail. And spam is so far a non-issue.

Or, host your own on your own metal, to avoid depending on any third party. Alternatively, if you are ok with semi-dependence on a third party, get a $5/mo Linux VPS, and host your E-mail there. With your own Linux instance, you can host whatever you want, have full control, can host other services too like www, git, whatever, and have the assurance that you're not going to suddenly lose access because AI-BOT-204432…

> How did we end up in this world where we so utterly rely on 3rd parties for such everyday critical Internet services?

For email? Because Google and Microsoft broke SMTP federation in the name of "anti-spam".

It's practically impossible to get Google, especially, to reliably deliver your email anymore if you aren't an actual email service provider.

Re: Don't use third party auth to sign in

#509

Post by jdeibele »

StavrosK wrote: post #506
u801e wrote: post #505

Earlier quoted context omitted.

How does the client identify itself during the SMTP or IMAP transaction?

It uses the password that you generated for it. I don't understand where the confusion is.

The confusion seems to be about logging into your account on the web versus using a mail client like Outlook or Thunderbird.

Pick a service that lets you use a long password and a security key (like Yubikey) or authenticator (Google, Authy) to log in.

Most services will then let you generate a specific password for an email client. I would assume that behind the scenes that the service is restricting what ports that password can be used on, etc.

Re: Don't use third party auth to sign in

#510

Post by u801e »

StavrosK wrote: post #506
u801e wrote: post #505

Earlier quoted context omitted.

How does the client identify itself during the SMTP or IMAP transaction?

It uses the password that you generated for it. I don't understand where the confusion is.

I don't understand how that's any more secure than just using a strong password for the account. At some point, you're going to have to make that password accessible to the client. Plus, it's arguably less secure because the account now has multiple valid passwords that will work for authentication, and, based on your description, there's nothing that prevents someone from using the exact same password over a netcat session from accessing the account.
Post reply on HN