Merge pull request #19 from pyqlsa/rephrasing

rephrasing for readability

pages/email-verification.md

@@ -39,7 +39,7 @@ The verification code should be at least 8 digits if the code is numeric, and at
 
 A single verification code should be tied to a single user and email. This is especially important if you allow users to change their email address after they're sent an email. Each code should be valid for at least 15 minutes (anywhere between 1-24 hours is recommended). The code must be single-use and immediately invalidated after validation. A new verification code should be generated every time the user asks for another email/code.
 
-Similar to a regular login form, throttling or rate-limiting based on the user ID must be implemented. A good limit is around 10 attempts per hour. Assuming proper limiting is implemented, the code can be valid for up to 24 hours. You should generate and resend a new code if the user-inputted code has expired.
+Similar to a regular login form, throttling or rate-limiting based on the user ID must be implemented. A good limit is around 10 attempts per hour. Assuming proper limiting is implemented, the code can be valid for up to 24 hours. You should generate and resend a new code if the user-provided code has expired.
 
 All sessions of a user should be invalidated when their email is verified.
 

pages/passkeys.md

@@ -55,7 +55,7 @@ const credentialId: string = publicKeyCredential.id;
 - `rp.name`: Your application's name
 - `user.id`: Random ID
 - `user.name`: Unique user identifier (user ID, username, email)
-- `user.displayName`: Does not need to unique
+- `user.displayName`: Does not need to be unique
 
 The algorithm ID is from the [IANA COSE Algorithms registry](https://www.iana.org/assignments/cose/cose.xhtml). ECDSA with SHA-256 (ES256) is recommended as it is widely supported. You can also pass `-257` for RSASSA-PKCS1-v1_5 (RS256) to support a wider range of devices but devices that only support it are rare.
 

pages/password-authentication.md

@@ -131,7 +131,7 @@ Finally, ensure a certain strength of passwords for users. Make sure passwords a
 
 As a good rule of thumb, error messages should be vague and generic. For example, a login form should display "Incorrect username or password" instead of "Incorrect username" or "Incorrect password." Similarly, a sign-in form shouldn't share whether a email is already used by an existing account.
 
-However, from a user-experience perspective, it's more user-friendly to tell the user directly that their username or email is incorrect. This should be fine for websites where usernames are already public (e.g. social media) or where knowing the validity of a email isn't important (i.e. most sites). This slightly makes brute-force attacks easier since attackers only need to guess passwords, but you should already have [proper measures](#brute-force-attacks) implemented.
+However, from a user-experience perspective, it's more user-friendly to tell the user directly that their username or email is incorrect. This should be fine for websites where usernames are already public (e.g. social media) or where knowing the validity of a email isn't important (i.e. most sites). This makes brute-force attacks slightly easier since attackers only need to guess passwords, but you should already have [proper measures](#brute-force-attacks) implemented.
 
 If you need to keep the username or email private, make sure you do not leak such information via registration forms and password reset forms. For example, when creating an account, you can prompt the user with a message like "We've sent an email to your inbox with further instructions" regardless of whether the email is taken. If they already have an account, you can include that information in the email itself. Even when returning a generic message however, it may be possible to determine if a user exists or not by checking the response times. For example, if you only validate the password when the username is valid. Protecting against timing-attacks is hard so only go this route if strictly required.
 

pages/sessions.md

@@ -95,12 +95,12 @@ The maximum expiration for a cookie is anywhere between 1 and 2 years. If you pl
 
 Another option is to store session IDs inside `localStorage` or `sessionStorage`. If your website has an XSS vulnerability, this will allow attackers to directly read and steal the user's session ID. It is especially vulnerable to supply chain attacks since tokens can be stolen by just reading the entire local storage, without using any application-specific exploits.
 
-Session tokens can be sent with the request using the `Authorization` header for example. Do not send them inside URLs as query parameters or inside form data, nor do not accept tokens sent in such ways.
+Session tokens can be sent with the request using the `Authorization` header for example. Do not send them inside URLs as query parameters or inside form data, nor should tokens sent in this manner be accepted.
 
 ## Session fixation attacks
 
-Applications that maintain sessions for both authenticated and unauthenticated users and reuses the current session when a user signs in, are vulnerable to session fixations attacks.
+Applications that maintain sessions for both authenticated and unauthenticated users and reuse the current session when a user signs in are vulnerable to session fixation attacks.
 
 Say an application allows the session ID to be sent inside the URL as a query parameter. If an attacker shares a link to the sign-in page with a session ID already included and the user signs in, the attacker now has a valid session ID to impersonate that user. A similar attack can be done if the application accepts session IDs in forms or cookies, though the latter requires an XSS vulnerability to exploit.
 
-This can be avoided by only accepting session IDs via cookies and request headers, and always creating a new session when the user signs in.
+This can be avoided by always creating a new session when the user signs in and only accepting session IDs via cookies and request headers.