Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proofreading fixes 0x04e #2278

Merged
merged 9 commits into from
Oct 17, 2022
Merged

Proofreading fixes 0x04e #2278

merged 9 commits into from
Oct 17, 2022

Conversation

Laancelot
Copy link
Contributor

typos, links

Thank you for submitting a Pull Request to the OWASP MASTG. Please make sure that:

  • Your contribution is written in the 2nd person (e.g. you)
  • Your contribution is written in an active present form for as much as possible.
  • You have made sure that the reference section is up to date (e.g. please add sources you have used, make sure that the references to MITRE/MASVS/etc. are up to date)
  • Your contribution has proper formatted markdown and/or code
  • Any references to website have been formatted as [TEXT](URL “NAME”)
  • You verified/tested the effectiveness of your contribution (e.g.: is the code really an effective remediation? Please verify it works!)

If your PR is related to an issue. Please end your PR test with the following line:
This PR closes #< insert number here >.

@cpholguera cpholguera changed the title Update 0x04e-Testing-Authentication-and-Session-Management.md Proofreading fixes for 0x04e - Testing-Authentication-and-Session-Management Oct 15, 2022
Copy link
Collaborator

@cpholguera cpholguera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Laancelot, could you please take a look at my suggestions? We can fix this section by removing a lot of content. Thank you!

Laancelot and others added 4 commits October 17, 2022 09:25
Commit suggestion

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Commit suggestion

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Commit suggestion

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Commit suggestion

Co-authored-by: Carlos Holguera <perezholguera@gmail.com>

In Android, the developer can use `Settings.Secure.ANDROID_ID` till Android 8.0 (API level 26) to identify an application instance. Note that starting at Android 8.0 (API level 26), `ANDROID_ID` is no longer a device unique ID. Instead, it becomes scoped by the combination of app signing key, user and device. So validating `ANDROID_ID` for device blocking could be tricky for these Android versions. Because if an app changes its signing key, the `ANDROID_ID` will change and it won't be able to recognize old users devices. Therefore, it's better to store the `ANDROID_ID` encrypted and privately in a private a shared preferences file using a randomly generated key from the `AndroidKeyStore` and preferably AES_GCM encryption. The moment the app signature changes, the application can check for a delta and register the new `ANDROID_ID`. The moment this new ID changes without a new application signing key, it should indicate that something else is wrong.
Next, the device binding can be extended by signing requests with a key stored in the `Keychain` for iOS and in the `KeyStore` in Android can reassure strong device binding.
You should also test if using different IPs, different locations and/or different time-slots will trigger the right type of information in all scenarios.

Lastly, the blocking of the devices should be tested, by blocking a registered instance of the app and see if it is then no longer allowed to authenticate.
Note: in case of an application which requires L2 protection, it can be a good idea to warn a user even before the first authentication on a new device. Instead: warn the user already when a second instance of the app is registered.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still find that sentence unclear? Sorry

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one "Note: in case of an application which requires L2 protection, it can be a good idea to warn a user even before the first authentication on a new device. Instead: warn the user already when a second instance of the app is registered."

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Me too, let's just remove them as I suggested in https://github.com/OWASP/owasp-mastg/pull/2278/files#r996281939. Line 561 is now taking care of this.

Copy link
Collaborator

@cpholguera cpholguera left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great improvements @Laancelot! Thanks!

@cpholguera
Copy link
Collaborator

With this we can merge, please take a look at the last 2 changes I've made to remove those lines.

#2278 (comment)
#2278 (comment)

@cpholguera cpholguera merged commit ab3645e into OWASP:master Oct 17, 2022
@cpholguera cpholguera changed the title Proofreading fixes for 0x04e - Testing-Authentication-and-Session-Management Proofreading fixes 0x04e May 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants