3 ms·

> Are you handling your own logins? Seems like a security issue waiting to happen! Can you explain what you mean by "handling your own logins" and what is the

> Are you handling your own logins? Seems like a security issue waiting to happen! Can you explain what you mean by "handling your own logins" and what is the norm?

neontomo 4y ago
Yes of course. Generally, for a project with a small team, doing the backend for logins yourself is a good way to get yourself hacked or having your customers data leaked at some point. It is difficult to do this type of validation and security testing well. The most likely outcome is that you overlooked something and later pay the price. On a small website I would default to using Google/FB/etc for logins and let them handle the security.
- PenguinCoder 4y ago
  That's pretty flimsy reasoning to allow Google and Facebook to track your users. You "might" have done something wrong. It's unlikely they rolled their own encryption and authentication process. Using well trusted, vetted, local auth libraries is much more preferable than outsourcing your auth for "security reasons" to a third party.
  - spockz 4y ago
    One could still use something like auth0 to implement authentication without shelling out to social media.
    - jeffybefffy519 4y ago
      Auth0 adds cost overhead for small projects that is hard to justify. I think the original comment about doing your own logins is overblown and theres still heaps of ways that outsourced logins can be broken from an integration POV.
- tryfinally 4y ago
  I, for one, wouldn't ever use a service that requires login via social media or some other platform, especially FB/Google. This isn’t usually a problem, though - I don’t think I’ve ever encountered an app that would impose this. (Maybe apart from services that are specifically built on top of the app that they’re authenticating through.)
  - WirelessGigabit 4y ago
    Tailscale comes to mind.
- thaumaturgy 4y ago
  Are you thinking the tricky part here is in handling password resets? Because otherwise I've had an easier time with straightforward username+bcrypt(password) in-house versus reliably implementing OAuth2/OpenID/whatever, which has some sharp edges of its own.
  - thiht 4y ago
    Agree with that. Honestly signup/login is not that hard to implement right, even from scratch. Also I don’t want FB/Google to know what I login to if I can avoid it.
- smcleod 4y ago
  Just please don't (only) rely on people having a Google or Facebook account. If they're all that's offered you're excluding a lot of people that don't want anything to do with those two companies.
- nobody9999 4y ago
  >On a small website I would default to using Google/FB/etc for logins and let them handle the security. And that would exclude many, including myself as I refuse to use the "services" provided by rapacious scumbags like Google and FB. Then again, OP is using Flutter, which is a Google jam. I wonder how long it will be before Google cancels it? All that said, why not suggest WebAuthn[0] or (Google again, short lifetime likely) Firebase instead? Especially since Firebase is a supported plug-in[1] for Flutter? [0] https://en.wikipedia.org/wiki/WebAuthn https://en.wikipedia.org/wiki/WebAuthn [1] https://pub.dev/packages/firebase_auth https://pub.dev/packages/firebase_auth
- tsuujin 4y ago
  It sounds like you’re asserting that any password login must have been rolled by hand from scratch, when in reality there are many great community built password login frameworks for basically any language and tooling combination you can think of. For example, if I’m using rails I can drop in Devise for a strong community tested user auth system. One that doesn’t let a marketing company track my usage.
- ipaddr 4y ago
  Rolling your own version is pretty straight forward as a single inexperienced developer. But most people use a framework with batteries included login functionality like password resets / rate liming. If it takes a medium sized team or a team something is off.
- deleted 4y ago
  [deleted]

> Are you handling your own logins? Seems like a security issue waiting to happen! Can you explain what you mean by "handling your own logins" and what is the norm?

neontomo 4y ago

Yes of course. Generally, for a project with a small team, doing the backend for logins yourself is a good way to get yourself hacked or having your customers data leaked at some point. It is difficult to do this type of validation and security testing well. The most likely outcome is that you overlooked something and later pay the price. On a small website I would default to using Google/FB/etc for logins and let them handle the security.

PenguinCoder 4y ago
That's pretty flimsy reasoning to allow Google and Facebook to track your users. You "might" have done something wrong. It's unlikely they rolled their own encryption and authentication process. Using well trusted, vetted, local auth libraries is much more preferable than outsourcing your auth for "security reasons" to a third party.
- spockz 4y ago
  One could still use something like auth0 to implement authentication without shelling out to social media.
  - jeffybefffy519 4y ago
    Auth0 adds cost overhead for small projects that is hard to justify. I think the original comment about doing your own logins is overblown and theres still heaps of ways that outsourced logins can be broken from an integration POV.
tryfinally 4y ago
I, for one, wouldn't ever use a service that requires login via social media or some other platform, especially FB/Google. This isn’t usually a problem, though - I don’t think I’ve ever encountered an app that would impose this. (Maybe apart from services that are specifically built on top of the app that they’re authenticating through.)
- WirelessGigabit 4y ago
  Tailscale comes to mind.
thaumaturgy 4y ago
Are you thinking the tricky part here is in handling password resets? Because otherwise I've had an easier time with straightforward username+bcrypt(password) in-house versus reliably implementing OAuth2/OpenID/whatever, which has some sharp edges of its own.
- thiht 4y ago
  Agree with that. Honestly signup/login is not that hard to implement right, even from scratch. Also I don’t want FB/Google to know what I login to if I can avoid it.
smcleod 4y ago
Just please don't (only) rely on people having a Google or Facebook account. If they're all that's offered you're excluding a lot of people that don't want anything to do with those two companies.
nobody9999 4y ago
>On a small website I would default to using Google/FB/etc for logins and let them handle the security. And that would exclude many, including myself as I refuse to use the "services" provided by rapacious scumbags like Google and FB. Then again, OP is using Flutter, which is a Google jam. I wonder how long it will be before Google cancels it? All that said, why not suggest WebAuthn[0] or (Google again, short lifetime likely) Firebase instead? Especially since Firebase is a supported plug-in[1] for Flutter? [0] https://en.wikipedia.org/wiki/WebAuthn https://en.wikipedia.org/wiki/WebAuthn [1] https://pub.dev/packages/firebase_auth https://pub.dev/packages/firebase_auth
tsuujin 4y ago
It sounds like you’re asserting that any password login must have been rolled by hand from scratch, when in reality there are many great community built password login frameworks for basically any language and tooling combination you can think of. For example, if I’m using rails I can drop in Devise for a strong community tested user auth system. One that doesn’t let a marketing company track my usage.
ipaddr 4y ago
Rolling your own version is pretty straight forward as a single inexperienced developer. But most people use a framework with batteries included login functionality like password resets / rate liming. If it takes a medium sized team or a team something is off.
deleted 4y ago
[deleted]