Typos

Document/0x05f-Testing-Local-Authentication.md

@@ -18,7 +18,7 @@ There are two ways of implementing local authentication:
 
 The first implementation, event-based, is inherently insecure for multiple reasons:
 
-- Somewhere in the application there will be an if/else that distinguishes between a successful or a failed authentication attempt. By tampering with the application at runtime, it is possible to convince the application that the authentication attempt was succesful.
+- Somewhere in the application there will be an if/else that distinguishes between a successful or a failed authentication attempt. By tampering with the application at runtime, it is possible to convince the application that the authentication attempt was successful.
 - After a legitimate successful authentication, the application will either present sensitive information to the user, or it will allow the user to perform a specific action. This means that either some data is stored locally which is not properly protected, or some functionality is not properly protected and can be triggered even without proper user authentication.
 
 The second implementation, result-based, is considered secure because:

tests-beta/android/MASVS-AUTH/MASTG-TEST-0x17-static.md

@@ -16,13 +16,13 @@ If the application uses event-based authentication instead of result-based authe
 ## Steps
 
 1. Identify keys created in the KeyStore which are protected by `setUserAuthenticationRequired`
-2. Identify how the key is used after the user has succesfully provided their biometrics or device credential. The exact method depends on the used API, but can include:
+2. Identify how the key is used after the user has successfully provided their biometrics or device credential. The exact method depends on the used API, but can include:
    1. BiometricPrompt.AuthenticationCallback.onAuthenticationSucceeded
    2. FingerprintManager.AuthenticationCallback.onAuthenticationSucceeded
 
 ## Observation
 
-The application may use the unlocked key to decrypt sensitive information, or it may simply continue with the flow and not use the key in any meaningful way. Note that only checking for the occurence of `setUserAuthenticationRequired` is not enough, as some applications will protect a key with user authentication in order to trigger the local authentication prompt, but not actually use it once it is unlocked.
+The application may use the unlocked key to decrypt sensitive information, or it may simply continue with the flow and not use the key in any meaningful way. Note that only checking for the occurrence of `setUserAuthenticationRequired` is not enough, as some applications will protect a key with user authentication in order to trigger the local authentication prompt, but not actually use it once it is unlocked.
 
 ## Evaluation