Skip to main content
added 86 characters in body
Source Link
John Wu
  • 9.4k
  • 2
  • 31
  • 40
  1. Avoid single-use tokens. These do not lend themselves well to fault tolerance, e.g. if a user tries to use a link and his device has a slow connection. Also, anything single-use may be more vulnerable to application denial of service attacks.

  2. Expire the token from a reasonable period after it is sent, e.g. 15 minutes.

  3. After the user clicks the link, require a second factor of authentication. This could be something very simple, like their name. This mitigates the risk that a typo in the user's email will grant full access to his account to a stranger with a similar address. For added security, the second factor could be delivered out of band (e.g. via SMS), but this is obviously less convenient. If you can't come up with a second factor, you can use a CAPCTHA, or if that is too strenuous for people, simply use a landing page with a button and require the user to click it before proceeding.

  4. Employ session fixation and CSRF mitigations on the authentication page(s)

  5. Expire any tokens in flight the moment the user authenticates successfully, but not before. This will prevent bots and email clients from accidentally consuming the code.

  6. Maintain an audit log of token use and analyze regularly for suspicious patterns.

  1. Avoid single-use tokens. These do not lend themselves well to fault tolerance, e.g. if a user tries to use a link and his device has a slow connection. Also, anything single-use may be more vulnerable to application denial of service attacks.

  2. Expire the token from a reasonable period after it is sent, e.g. 15 minutes.

  3. After the user clicks the link, require a second factor of authentication. This could be something very simple, like their name. This mitigates the risk that a typo in the user's email will grant full access to his account to a stranger with a similar address. For added security, the second factor could be delivered out of band (e.g. via SMS), but this is obviously less convenient. If you can't come up with a second factor, you can use a CAPCTHA, or if that is too strenuous for people, simply use a landing page with a button and require the user to click it before proceeding.

  4. Employ session fixation and CSRF mitigations on the authentication page(s)

  5. Expire any tokens in flight the moment the user authenticates successfully, but not before. This will prevent bots and email clients from accidentally consuming the code.

  1. Avoid single-use tokens. These do not lend themselves well to fault tolerance, e.g. if a user tries to use a link and his device has a slow connection. Also, anything single-use may be more vulnerable to application denial of service attacks.

  2. Expire the token from a reasonable period after it is sent, e.g. 15 minutes.

  3. After the user clicks the link, require a second factor of authentication. This could be something very simple, like their name. This mitigates the risk that a typo in the user's email will grant full access to his account to a stranger with a similar address. For added security, the second factor could be delivered out of band (e.g. via SMS), but this is obviously less convenient. If you can't come up with a second factor, you can use a CAPCTHA, or if that is too strenuous for people, simply use a landing page with a button and require the user to click it before proceeding.

  4. Employ session fixation and CSRF mitigations on the authentication page(s)

  5. Expire any tokens in flight the moment the user authenticates successfully, but not before. This will prevent bots and email clients from accidentally consuming the code.

  6. Maintain an audit log of token use and analyze regularly for suspicious patterns.

Source Link
John Wu
  • 9.4k
  • 2
  • 31
  • 40

  1. Avoid single-use tokens. These do not lend themselves well to fault tolerance, e.g. if a user tries to use a link and his device has a slow connection. Also, anything single-use may be more vulnerable to application denial of service attacks.

  2. Expire the token from a reasonable period after it is sent, e.g. 15 minutes.

  3. After the user clicks the link, require a second factor of authentication. This could be something very simple, like their name. This mitigates the risk that a typo in the user's email will grant full access to his account to a stranger with a similar address. For added security, the second factor could be delivered out of band (e.g. via SMS), but this is obviously less convenient. If you can't come up with a second factor, you can use a CAPCTHA, or if that is too strenuous for people, simply use a landing page with a button and require the user to click it before proceeding.

  4. Employ session fixation and CSRF mitigations on the authentication page(s)

  5. Expire any tokens in flight the moment the user authenticates successfully, but not before. This will prevent bots and email clients from accidentally consuming the code.