521–530 of 544 posts
I only ever use "sign in with" for throaway stuff I don't care enough about to register an account - if it's in any way important I setup an account, and add whatever form of 2FA I can.
I really wish 2fa was implemented in convenient form everywhere. There are ton of sites that just force me to use SMS.
Earlier quoted context omitted.
- does you registrar have physical office? is it in a country with legislation friendly towards the country you're based in? - does your registrar send Auth-Info code over email in plain text? - did you enter real contact and residence data when registering the domain including public WHOIS database? This is only a fraction of the attack vector.
> does you registrar have physical office? Yes. > is it in a country with legislation friendly towards the country you're based in? It's in the same country. > does your registrar send Auth-Info code over email in plain text? Of course not, that would be a big red-flag. > did you enter real contact and residence data when registering the domain including public WHOIS database? I have no idea what a public WHOIS datab…
The WHOIS client is in most distros, try it out.
Earlier quoted context omitted.
Phishing or bribing an employee at a domain registrar. Phishing you to get your password and then bribing or social-engineering someone at the phone company to forward your SMS-based 2FA codes to them. Waiting for you to forget to renew your domain and then registering it.
> Phishing or bribing an employee at a domain registrar. Okay? I don't think anyone would go to that trouble. > Phishing you to get your password and then bribing or social-engineering someone at the phone company to forward your SMS-based 2FA codes to them. Seems unlikely, I never log into my registrar's website. I do often have to enter my Google password though! > Waiting for you to forget to renew your domain and…
Consider that you have a github account. You might be in the supply chain for a bit of code someone needs to read or backdoor to attack a company that you've never heard of. Github is a harder target though.
The scary ones are the real estate funds redirectors. They just need to be in your inbox for a little bit and boom, hundreds of thousands of $ gone because people don't take the time to re-verify bank account details by in person.
Earlier quoted context omitted.
I don't want more accounts and passwords. The security seems strictly worse than just authenticating against my email provider directly.
There's no good reason not to use a password manager in 2020. I recommend this one: https://www.passwordstore.org/
Earlier quoted context omitted.
I don't want more accounts and passwords. The security seems strictly worse than just authenticating against my email provider directly.
password managers are a thing. Takes literally 20 seconds to add a new one to a new account.
Earlier quoted context omitted.
It's a step in the right direction, but it's still centralized. A lot of the work done by the Indie Web community around IndieAuth[1] is really attractive. Your identity is your domain, and you can change how your domain says you're allowed to authenticate. Now you can even use sign-in with google without getting locked out should you loose your google account. Aligns really well with using your own domain for email…
I'm a bit divided on whether or not the "centralized" thing is actually a problem Promise should tackle. On one hand, I want to tell you that Promise is only centralized by default. Which is good for people that doesn't understand what a OpenID/IndieAuth Provider is. But as Promise is open source and the protocol caters for it, it is possible to have Promise redirect authentication requests to your own instance. Whic…
The challenge with centralized is that it is a single point of failure. The original post was more focused on "If you get locked out of google, you get locked out of everything". In that vein if promise gets hacked/bought/abandoned/changes it's business model etc.. then you lose all your accounts. The anonymous nature of it is great, but this is something Apple already offers with their sign-in with apple which is already widely supported and with the proxy-email solution you can still be contacted by the sites you're signing up with.
I got interested in IndieAuth because of a project of mine[2], trying to make it really easy for everyone to self-host their facebook/twitter equivalent with direct control over who has access. This runs into the problem with wide adoption where you have a separate credential for each of your friends' blogs. With IndieAuth built into the self-hosted platform, then your own self-hosted site becomes the one credential you can use on all your friends' sites. Self-hosted distributed identity for privacy AND ease-of-use.
[1] https://wordpress.org/plugins/indieauth/ [2] You can find the link in other comments I've made on HN
Earlier quoted context omitted.
It's a step in the right direction, but it's still centralized. A lot of the work done by the Indie Web community around IndieAuth[1] is really attractive. Your identity is your domain, and you can change how your domain says you're allowed to authenticate. Now you can even use sign-in with google without getting locked out should you loose your google account. Aligns really well with using your own domain for email…
I hadn't heard of either Promise or IndieAuth before reading this thread, so apologies if this is a dumb question. But one of the benefits of Promise is that it's pseudonymous: > You will get a unique identity pr. service you use. This ensures that relying parties have no way to profile you across services. For me, this is actually the biggest reason that I stopped using social sign-ins. It's not that Google might di…
That said, the unique identity is still valuable--Apple offers this with their third party sign in[1]. Practically, if everyone was using self-hosted identity, then the tools would probably make it easy for you to create and track your own new identities for each service you use. This isn't build into something like IndieAuth today, but with the right DNS settings you could have arbitrary subdomains return the same authentication options and act as easy-to-use "sub identities".
Earlier quoted context omitted.
Only issue with not using GSuite is that you won’t be able to DKIM sign those emails, although just SPF might be sufficient.
You can also use Gmail as POP3/SMTP client for your e-mail account at other provider.
Earlier quoted context omitted.
I'm a bit divided on whether or not the "centralized" thing is actually a problem Promise should tackle. On one hand, I want to tell you that Promise is only centralized by default. Which is good for people that doesn't understand what a OpenID/IndieAuth Provider is. But as Promise is open source and the protocol caters for it, it is possible to have Promise redirect authentication requests to your own instance. Whic…
You're right that the user experience is a huge blocker, but I think that's something we as authors of tools can improve on. For example, there's a Wordpress plugin that lets your Wordpress site act as an IndieAuth identity[1]. That makes it pretty usable from and end-user perspective. The challenge with centralized is that it is a single point of failure. The original post was more focused on "If you get locked out…
I totally understand what makes IndieAuth is a good solution. And it seems really easy. For me. But I have no idea how I would go about explaining it to, let's say, my mom.
Apple is offering something very similar to what Promise does. The difference is that Apple is a commercial corporation. Which means they're in the game to make money. Promise will be in the game to make authentication easy, secure and private.
In many ways I compare the goal of Promise, with the goal of DNS. Take a commodity and make it available globally in a reliable way. Yes, it will be a single point of failure. So the job of Promise will in large be, to keep the platform secure and reliable.