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

511–520 of 544 posts

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

#511

Post by u801e »

jdeibele wrote: post #509
StavrosK wrote: post #506

Earlier quoted context omitted.

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…

> I would assume that behind the scenes that the service is restricting what ports that password can be used on

Assuming it's a device accessing the service over IMAP and SMTP that can access multiple networks, restricting by IP and/or port won't really help. As I noted in my other reply, it's easy enough to script access to the account if have the password and there's no real association between the application and the credentials that are used for access.

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

#512

Post by senectus1 »

bsder wrote: post #507
TedDoesntTalk wrote: post #471

Earlier quoted context omitted.

> [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 "ce…

Any tool used to create another tool, is the very tool that will be used to help dismantle that other tool.

There is no way around this... Security isn't a state, it s a process. It relies on the human to propagate it. A bit like a garden.

Make the process simple for the user (but not thoughtless) and that is about as good as is going to get.

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

#513

Post by angry_octet »

yosamino wrote: post #83
angry_octet wrote: post #61

Good point, but if Google suspends my account I've got bigger things to worry about than the dozens of sites I've used once or twice a year. Paying for your own domain also comes with its own troubles. If you're not using Google (or some other service) as your mail forwarder, good luck being able to email anyone. Stealing you custom domain is also a real possibility, and negates your investment in Gmail 2FA.

Running a mailserver is something that doesn't just work out of the box, but it's not true that it's impossible to run a relatively reliable email service. Takes a bit of work, for sure. But it's the best and biggest federated network we have at the moment. Your custom domain can be secured by 2FA as well, if one is using a reputable registrar, and you can legally own it. So even if it's stolen, there is recourse. I…

> it's not true that it's impossible to run a relatively reliable email service

Good thing I didn't say that then.

Running your own email service isn't hard, even with setting up DKIM and anti-spam and so on, though it is time consuming. It is much harder to make sure people will receive your mail and it not be in their junk mail. I'm still seeing lots of email to mailing lists, with impeccable message content, ending up in spam based on mail server reputation or content similarity metrics. If you're running an organisation that can be very costly. If only a fraction of your recipients mark you as spam you'll get lots of misses.

Handcrafting your own internet stack is very libertarian, but it doesn't scale to anyone without access to deep tech expertise. Even governments decide they can't run mail any more. And I would argue that this isn't something you can fix about email. The problem is that the next system isn't federated at all -- it's balkanised and monetized: WhatsApp/Messenger, iMessage, Duo, Telegram, etc etc.

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

#514

Post by SquareWheel »

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.

Useful, thank you.

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

#515

Post by anderslemke »

dkdk8283 wrote: post #492
anderslemke wrote: post #275

The risk of getting your account locked is just one of the reasons you shouldn't use Google (and the like) to sign in. But how did we end up in this horrible state of authentication? Why don't we have something as easy to use as the DNS, but for authentication? Imagine what authentication would look like, if we all started running is the same direction, instead of implementing our own authentication again and again.…

I see it as a stepping stone for global “real id”. In this case centralization is a feature, not a bug.

That is an interesting point.

Internet identity could maybe be a layered thing where one layer takes care of authentication, which is where Promise lives. The next layer could handle information like name and email. And finally a layer that handles your verified identity by an authority. That last layer is where the danish NemID fits in.

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

#516

Post by anderslemke »

sedatk wrote: post #504
anderslemke wrote: post #305

Earlier quoted context omitted.

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?

Being a non-profit, collectively owned service, which Promise is, will make it difficult to ban users and relying parties.

Just like the DNS can block users, Promise can ban users and relying parties.

This is not something Promise should take lightly, but the fact that almost everyone has a say in Promise, unlike Google, where almost no one has a say, makes me full of hope that this can be solved in a transparent way.

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

#517

Post by ukoki »

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?

I meant using TOTP (app-based) two-factor authentication for securing your DNS provider and domain registrar accounts. The reason for not using SMS-based two-factor authentication is that it is not very secure https://techcrunch.com/2016/07/25/nist-declares-the-age-of-s...

I'm not aware of two-factor authentication for SMTP or IMAP.

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

#518

Post by jsilence »

nottorp wrote: post #161
_odey wrote: post #59

Earlier quoted context omitted.

This might sound like sarcasm to us but I've honestly heard people claim this with a serious face, as well as: "I'm not doing anything bad, so they'll never block me". Guess it's not a problem until it actually happens to them.

There were pieces of news about google accounts being blocked for being "associated" with an account that did bad things. I think most were contractors using both their own accounts and the customer's accounts to put apps in the play store... which will associate you with random people that pay you to make an app, maybe forever?

Having an identity provider service intermingled with services by the same company and not differentiating between providing the identity service and any other service is the core of this problem.

Really sad that Mozilla Persona did not make it. To me this was promising solution for 'identity provider service'. This section of service should be heavily regulated since it hs a lot of power.

Also probably it should be paid for.

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

#519

Post by agapon »

glokk wrote: post #484
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…

Once you have your domain, you can use Zoho create emails for your domain for free. They don't offer IMAP/POP3 access in the free tier though.

Or register a domain with Gandi and they provide a free email service to you. Only two free accounts (with "unlimited" aliases), but that should be sufficient for most personal uses.

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

#520

Post by GordonS »

u801e wrote: post #495
zajio1am wrote: post #462

Earlier quoted context omitted.

There is TLS client authentication, unfortunately it never catched on, probably due to not good and uniform UX in browsers. Imagine if web-browsers have automatically generated password-protected self-signed certificates that could be used to authenticate to web services without need of any third-party.

> Imagine if web-browsers have automatically generated password-protected self-signed certificates that could be used to authenticate to web services without need of any third-party. What should be done when creating a new account is that, in addition to the username and password, the website should allow for uploading a certificate signing request. The web browser should then allow the user to create one and upload…

>×The web browser should then allow the user to create one and upload it

Your average user is not going to open a command prompt and dig into Openssl. There are (or were, I haven't used them for a decade) browser-specific APIs for generating private keys locally, but they were very flakey, and the whole UX was very confusing for users.

And after this, the user can only sign in on the machine in which the key was created. Your average user will not have a clue how to move certificates and keys around between machines.

I have direct experience with this. Back in 2008 I led a team building an extranet site, and we used X.509 client certificate authentication. We had to build our own tooling for management of the PKI, which was no small task. But ultimately it was key creation and certificate distribution that were the biggest problem - our users absolutely hated the signup process, as well as the fact that they couldn't later signin on another machine.

Post reply on HN