7 ms·

Original article from Dev.to: https://dev.to/simplelogin/if-you-care-about-user-privacy-do-not-use-facebook-js-sdk-1j3e https://dev.to/simplelogin/if-you-care-a

Original article from Dev.to: https://dev.to/simplelogin/if-you-care-about-user-privacy-do-not-use-facebook-js-sdk-1j3e https://dev.to/simplelogin/if-you-care-about-user-privacy-do... I've recently implemented authentication for my project and I would just like to say to all the relatively amateur programmers out there: for web based authentication just stick with HTTPOnly SECURE cookies with DB backed sessions that you can revoke. The reason I'm saying this is that there's way too many posts talking about JWT (which isn't suitable for newbies), Oauth (which is more useful if you have separate authentication and resource servers) and other token based mechanisms which are what cookies are except more suitable for non web based clients.

emmaglossy 7y ago
I think even when integrating a social login, a developer still needs to create a secure cookie and has "user" table in his/her database. Using social login is rather a convenient option for users as they don't have to create a new account.
- wool_gather 7y ago
  Sure, but the stored credential is not reusable in another context. Which is not true for the majority of passwords. As a bonus, the authorization is probably also revocable via the external identity provider, although that's more about service-to-service permissions than account compromise.
sgn 7y ago
Yes, I'm in favour of using Secure Cookies for authentication. But, the TDD (Trend Driven Development) people won't agree with them. They want to work with those shiny trends for a shiny resume. JWT is horrible for the web, it need JavaScript, some needs Local Storage, which is worse than Cookies itself, and the revocation is complex.
mac_was 7y ago
I don't think that storing creds is suitable for newbies either. All authentication is complex and just using HTTPOnly and DB backend is not a solution at all.
- r_singh 7y ago
  Depends on what the project is and also doesn't change the fact that this doesn't happen. Most solo bootstrapped projects are not popular enough initially for someone to spend money / effort to hack them. When they do become somewhat popular though (very small minority of course), I suspect most founders bring experts on board, as they absolutely should. > just using HTTPOnly and DB backend is not a solution at all My comment was not meant to be exhaustive and does not list all vulnerabilities. Just in context of some of the suggestions in the article. Using a mature framework like Django can protect you from other vulnerabilities CSRF, XSS, SQL Injection to some extent.
  - jonnypotty 7y ago
    >most founders bring experts on-board You have way too much faith my friend. How does bringing an authentication and security expert into your organization make you more money? It doesn't. What people like this tell you change is all cost and only hypothetical benifit. I suspect this doesnt happen anywhere near as much as it should.
  - some_random 7y ago
    >Most solo bootstrapped projects are not popular enough initially for someone to spend money / effort to hack them. Strong contender for Most Horrifying Thing I've Read This Morning.
    - mandelbrotwurst 7y ago
      It's good practice to consider the likelihood of attack in your threat model if you care about the expected payoff associated with your security efforts.
      - Karunamon 7y ago
        When that threat model necessarily includes bored script kiddies and automated APTs?
    - 7y ago
scarface74 7y ago
This is a bad piece of advice. Two things I don’t ever want to take responsibility for when starting a project are user authentication and payment processing. I think I know best practices for each, but so does everyone who has gotten hacked.
- geofft 7y ago
  I don't disagree with you, but the state of affairs is basically a protection racket. If you sell out your users to Facebook, they'll keep you safe from all the other attackers.
  - scarface74 7y ago
    Most frameworks come with their own authentication module. I still wouldn’t write my own.
TimMurnaghan 7y ago
I get the motivation of what you're saying - but I'm going more towards splitting the back end from knowing too much. Do authentication in a proxy layer (can deploy as a sidecar if suitably containerized) and then have a bearer token between the proxy and the app server. Yes it's a lot of "architecture" for a newby but it generalizes well to the byzantine Oauth cases without requiring too mach app rewrtiting and this kind of service split is pretty do-able given a Paas.
StreamBright 7y ago
Do you think that registration can include solutions like Github? I am not sure how to handle after. Login with the 3rd party would trigger a http only secure cookie creation and insertion into the db? I want to avoid JWT and co. especially after watching so many videos about the downsides and the potential security implications.

emmaglossy 7y ago

I think even when integrating a social login, a developer still needs to create a secure cookie and has "user" table in his/her database. Using social login is rather a convenient option for users as they don't have to create a new account.

wool_gather 7y ago
Sure, but the stored credential is not reusable in another context. Which is not true for the majority of passwords. As a bonus, the authorization is probably also revocable via the external identity provider, although that's more about service-to-service permissions than account compromise.

sgn 7y ago

Yes, I'm in favour of using Secure Cookies for authentication. But, the TDD (Trend Driven Development) people won't agree with them. They want to work with those shiny trends for a shiny resume. JWT is horrible for the web, it need JavaScript, some needs Local Storage, which is worse than Cookies itself, and the revocation is complex.

mac_was 7y ago

I don't think that storing creds is suitable for newbies either. All authentication is complex and just using HTTPOnly and DB backend is not a solution at all.

r_singh 7y ago
Depends on what the project is and also doesn't change the fact that this doesn't happen. Most solo bootstrapped projects are not popular enough initially for someone to spend money / effort to hack them. When they do become somewhat popular though (very small minority of course), I suspect most founders bring experts on board, as they absolutely should. > just using HTTPOnly and DB backend is not a solution at all My comment was not meant to be exhaustive and does not list all vulnerabilities. Just in context of some of the suggestions in the article. Using a mature framework like Django can protect you from other vulnerabilities CSRF, XSS, SQL Injection to some extent.
- jonnypotty 7y ago
  >most founders bring experts on-board You have way too much faith my friend. How does bringing an authentication and security expert into your organization make you more money? It doesn't. What people like this tell you change is all cost and only hypothetical benifit. I suspect this doesnt happen anywhere near as much as it should.
- some_random 7y ago
  >Most solo bootstrapped projects are not popular enough initially for someone to spend money / effort to hack them. Strong contender for Most Horrifying Thing I've Read This Morning.
  - mandelbrotwurst 7y ago
    It's good practice to consider the likelihood of attack in your threat model if you care about the expected payoff associated with your security efforts.
    - Karunamon 7y ago
      When that threat model necessarily includes bored script kiddies and automated APTs?
  - 7y ago

scarface74 7y ago

This is a bad piece of advice. Two things I don’t ever want to take responsibility for when starting a project are user authentication and payment processing. I think I know best practices for each, but so does everyone who has gotten hacked.

geofft 7y ago
I don't disagree with you, but the state of affairs is basically a protection racket. If you sell out your users to Facebook, they'll keep you safe from all the other attackers.
- scarface74 7y ago
  Most frameworks come with their own authentication module. I still wouldn’t write my own.

TimMurnaghan 7y ago

I get the motivation of what you're saying - but I'm going more towards splitting the back end from knowing too much. Do authentication in a proxy layer (can deploy as a sidecar if suitably containerized) and then have a bearer token between the proxy and the app server. Yes it's a lot of "architecture" for a newby but it generalizes well to the byzantine Oauth cases without requiring too mach app rewrtiting and this kind of service split is pretty do-able given a Paas.

StreamBright 7y ago

Do you think that registration can include solutions like Github? I am not sure how to handle after. Login with the 3rd party would trigger a http only secure cookie creation and insertion into the db? I want to avoid JWT and co. especially after watching so many videos about the downsides and the potential security implications.