3 ms·

>2. Don't use passwords. >It's 2018. Passwords are really not a good way to secure your system. You're going to end up building an email-based password reset s

>2. Don't use passwords. >It's 2018. Passwords are really not a good way to secure your system. You're going to end up building an email-based password reset system anyway right? So just cut to the chase and use magic-link based login only. It's pretty easy to do securely. I'm no security expert but isn't email notoriously insecure? I also find checking my email every time I have to log into a service or app is poor user experience. Are there better even more secure ways of implementing a no password system?

BillinghamJ 9y ago
As with many things, it depends. If you were planning on enabling email-based password reset anyway - as most sites do - then there is no degradation in security. Magic link tokens are one-time-use anyway, so assuming you follow the authorization code spec, if any attempt is made to use the code a second time, you should revoke any existing auth tokens which resulted from that code. So the risk here is pretty low. You can also further mitigate this by implementing PKCE, which prevents any other client/app/whatever from using the code. Also bear in mind most apps are able to store access/refresh tokens securely, so don't tend to have any kind of auth timeout. For most apps which allow magic-link login, your "session" will never expire, so it isn't particularly problematic to have to log in via an email link. For a website, there's no major reason you shouldn't have a reasonably long-lasting cookie to prevent any need for regular login. If you're concerned about long-lasting sessions, it might be appropriate to use a second authentication factor for sensitive actions - e.g. purchases, transferring money, etc. Other than pairing with MFA/2FA, there isn't really anything meaningfully more secure than (properly implemented) email magic link auth. Assuming you want decent usability and your audience isn't overly technical, magic links are definitely the way to go as a primary authentication mechanism.
- JeanMarcS 9y ago
  > For a website, there's no major reason you shouldn't have a reasonably long-lasting cookie to prevent any need for regular login. What happens if the cookie is stolen (real question) ? Wasn't that the problem in keeping connection / session information in cookies back in the days ?
  - BillinghamJ 9y ago
    There are lots of effective mechanisms to prevent the stealing of cookies. If you have a client-side-only site, probably best to use local storage instead. Otherwise, marking them as HTTP-only and secure-only should be sufficient.
    - JeanMarcS 9y ago
      Thank you.

BillinghamJ 9y ago

As with many things, it depends. If you were planning on enabling email-based password reset anyway - as most sites do - then there is no degradation in security. Magic link tokens are one-time-use anyway, so assuming you follow the authorization code spec, if any attempt is made to use the code a second time, you should revoke any existing auth tokens which resulted from that code. So the risk here is pretty low. You can also further mitigate this by implementing PKCE, which prevents any other client/app/whatever from using the code. Also bear in mind most apps are able to store access/refresh tokens securely, so don't tend to have any kind of auth timeout. For most apps which allow magic-link login, your "session" will never expire, so it isn't particularly problematic to have to log in via an email link. For a website, there's no major reason you shouldn't have a reasonably long-lasting cookie to prevent any need for regular login. If you're concerned about long-lasting sessions, it might be appropriate to use a second authentication factor for sensitive actions - e.g. purchases, transferring money, etc. Other than pairing with MFA/2FA, there isn't really anything meaningfully more secure than (properly implemented) email magic link auth. Assuming you want decent usability and your audience isn't overly technical, magic links are definitely the way to go as a primary authentication mechanism.

JeanMarcS 9y ago
> For a website, there's no major reason you shouldn't have a reasonably long-lasting cookie to prevent any need for regular login. What happens if the cookie is stolen (real question) ? Wasn't that the problem in keeping connection / session information in cookies back in the days ?
- BillinghamJ 9y ago
  There are lots of effective mechanisms to prevent the stealing of cookies. If you have a client-side-only site, probably best to use local storage instead. Otherwise, marking them as HTTP-only and secure-only should be sufficient.
  - JeanMarcS 9y ago
    Thank you.