Update Authentication_Cheat_Sheet.md

[philCryoport]

Thank you for submitting a Pull Request (PR) to the Cheat Sheet Series.

🚩 If your PR is related to grammar/typo mistakes, please double-check the file for other mistakes in order to fix all the issues in the current cheat sheet.

Please make sure that for your contribution:

• In case of a new Cheat Sheet, you have used the Cheat Sheet template.
• All the markdown files do not raise any validation policy violation, see the policy.
• All the markdown files follow these format rules.
• All your assets are stored in the assets folder.
• All the images used are in the PNG format.
• Any references to websites have been formatted as TEXT
• You verified/tested the effectiveness of your contribution (e.g., the defensive code proposed is really an effective remediation? Please verify it works!).
• The CI build of your PR pass, see the build status here.

If your PR is related to an issue, please finish your PR text with the following line:

This PR covers issue #1243

Thank you again for your contribution 😃

[philCryoport]

Am I reading this correctly -- where there needs to be a code-owner approval before linting happens?

I would rather know my content fails linting -- and correct that -- before sending it for code-owner approval.

Also, seems like linting is also blocked when a PR is in draft state. Again, there it would be useful to know if my content fails linting...

[philCryoport]

Never mind, I found where it was buried in the contribution guide

[philCryoport]

Ok Markdown plugin no longer complaining in VSCodium

[jmanico]

I feel this guidance is more verbose than it needs to be. For starters, we can drop the MFA part and some of the less-than-necessary steps. For example, maybe one list like this?

1. New Email Submission: Request and validate the new email address for an authenticated user.
2. Identity Verification: Require re-authentication to verify user identity.
3. Send a notification to the old email address regarding the change request.
4. Send a confirmation request to the new email with a confirmation link.
5. If confirmed, update the email address.

This is just a cheat-sheet, I want to keep the guidance short and to the point.

Thank you!

[philCryoport]

I feel this guidance is more verbose than it needs to be. For starters, we can drop the MFA part and some of the less-than-necessary steps. For example, maybe one list like this?

1. New Email Submission: Request and validate the new email address for an authenticated user.

2. Identity Verification: Require re-authentication to verify user identity.

3. Send a notification to the old email address regarding the change request.

4. Send a confirmation request to the new email with a confirmation link.

5. If confirmed, update the email address.

This is just a cheat-sheet, I want to keep the guidance short and to the point.

Thank you!

Hi @jmanico

Agreed, this is a cheat sheet, so I'll shorten the section.

However, I'd still like to offer up these step-by-step processes if OWASP agrees they are the correct way to prevent an account takeover.

Should I publish these in https://owasp.org/www-community/controls/ ?

Is there a better place to publish them?

[jmanico]

I do like this content, but it's a little sloppy and the language needs to be cleaned up. And needs to be massively reduced. I'll help when I can, this is a very solid idea, it just needs a lot of cleanup.

[jmanico]

I feel this guidance is more verbose than it needs to be. For starters, we can drop the MFA part and some of the less-than-necessary steps. For example, maybe one list like this?

1. New Email Submission: Request and validate the new email address for an authenticated user.

2. Identity Verification: Require re-authentication to verify user identity.

3. Send a notification to the old email address regarding the change request.

4. Send a confirmation request to the new email with a confirmation link.

5. If confirmed, update the email address.

This is just a cheat-sheet, I want to keep the guidance short and to the point.
Thank you!

Hi @jmanico

Agreed, this is a cheat sheet, so I'll shorten the section.

However, I'd still like to offer up these step-by-step processes if OWASP agrees they are the correct way to prevent an account takeover.

Should I publish these in https://owasp.org/www-community/controls/ ?

Is there a better place to publish them?

And yes a community page is the right place for the total content and I can help you clean it up. AI can help. Send all your text into a LLM and ask for cleanup and you'll see what I mean.

[philCryoport]

I feel this guidance is more verbose than it needs to be. For starters, we can drop the MFA part and some of the less-than-necessary steps. For example, maybe one list like this?

1. New Email Submission: Request and validate the new email address for an authenticated user.

2. Identity Verification: Require re-authentication to verify user identity.

3. Send a notification to the old email address regarding the change request.

4. Send a confirmation request to the new email with a confirmation link.

5. If confirmed, update the email address.

This is just a cheat-sheet, I want to keep the guidance short and to the point.
Thank you!

Hi @jmanico
Agreed, this is a cheat sheet, so I'll shorten the section.
However, I'd still like to offer up these step-by-step processes if OWASP agrees they are the correct way to prevent an account takeover.
Should I publish these in owasp.org/www-community/controls ?
Is there a better place to publish them?

And yes a community page is the right place for the total content and I can help you clean it up. AI can help. Send all your text into a LLM and ask for cleanup and you'll see what I mean.

Roger that.

[philCryoport]

Hi @jmanico LLM indeed cleaned it up. How is it now?

[philCryoport]

Thank you!