Minor changes for threat model chapter.

topics/threat/brute-force.adoc

@@ -13,13 +13,13 @@ image:../../{{book.images}}/brute-force.png[]
 The way this works is that if there are `Max Login Failures` during a period of `Failure Reset Time`,
 the account is temporarily disabled for the `Wait Increment` multiplied by the number of failures over the max.  After
 `Failure Reset Time` is reached all failures are wiped clean.  The `Max Wait` is the maximum amount of time
-an account can be disabled for.  Another preventive measure is that if there is subsequent login failures for one
+an account can be disabled.  Another preventive measure is that if there are subsequent login failures for one
-account that are too quick for a human to initiate the account will be disabled then.  This is controlled by the
+account that are too quick for a human to initiate the account will be disabled.  This is controlled by the
 `Quick Login Check Milli Seconds` value.  So, if there are two login failures for the same account within that value,
 the account will be disabled for `Minimum Quick Login Wait`.
 
 The downside of {{book.project.name}} brute force detection is that the server becomes vulnerable to denial of service attacks.
-An attacker can simply try to guess passwords for as many accounts it knows and these account will be disabled.  Eventually
+An attacker can simply try to guess passwords for any accounts it knows and these account will be disabled.
 Eventually we will expand this functionality to take client IP address into account when deciding whether to block a user.
 
 A better option might be a tool like http://fail2ban.org[Fail2Ban].  You can point this service at the {{book.project.name}} server's log file.
@@ -28,7 +28,7 @@ firewalls after it detects an attack to block connections from specific IP addre
 
 ==== Password Policies
 
-Another things you should do to prevent password guess is to have a complex enough password policy to ensure that
+Another thing you should do to prevent password guess is to have a complex enough password policy to ensure that
 users pick hard to guess passwords.  See the <<fake/../../authentication/password-policies.adoc#_password-policies, Password Policies>> chapter for more details.
 
 The best way to prevent password guessing though is to set up the server to use a one-time-password (OTP).

topics/threat/clickjacking.adoc

@@ -6,10 +6,9 @@ buttons that are carefully constructed to be placed directly under important but
 When a user clicks a visible button, they are actually clicking a button (such as a "login" button) on the hidden page.
 An attacker can steal a user's authentication credentials and access their resources.
 
-By default, every response by {{book.project.name}} sets some specific browser headers that can prevent this from happening
+By default, every response by {{book.project.name}} sets some specific browser headers that can prevent this from happening.
-specifically http://tools.ietf.org/html/rfc7034[X-FRAME_OPTIONS] and http://www.w3.org/TR/CSP/[Content-Security-Policy].
+Specifically, it sets http://tools.ietf.org/html/rfc7034[X-FRAME_OPTIONS] and http://www.w3.org/TR/CSP/[Content-Security-Policy].
-You should take a look at the definition of both of these headers as there is a lot of fine-grain browser access you can control
+You should take a look at the definition of both of these headers as there is a lot of fine-grain browser access you can control.
-with these headers.
 In the admin console you can specify the values these headers will have.  Go to the `Realm Settings` left menu item and
 click the `Security Defenses` tab and make sure you are on the `Headers` sub-tab.
 

topics/threat/compromised-codes.adoc

@@ -1,7 +1,7 @@
 
 === Compromised Access Codes
 
-For the <<fake/../../sso-protocols/oidc.adoc#_oidc-auth-flows, OIDC Auth Code Flow>>, t would be very hard for an attacker to compromise {{book.project.name}} access codes.
+For the <<fake/../../sso-protocols/oidc.adoc#_oidc-auth-flows, OIDC Auth Code Flow>>, it would be very hard for an attacker to compromise {{book.project.name}} access codes.
 {{book.project.name}} generates a cryptographically strong random value for its access codes so it would be very hard to guess an access token.
 An access code can only be used once to obtain an access token.
 In the admin console you can specify how long an access token is valid for on the <<fake/../../sessions/timeouts.adoc#_timeouts, timeouts page>>.

topics/threat/compromised-tokens.adoc

@@ -1,7 +1,7 @@
 
 === Compromised Access and Refresh tokens
 
-There's a few things you can do to mitigate access tokens and refresh tokens from being stolen.
+There are a few things you can do to mitigate access tokens and refresh tokens from being stolen.
 The most important thing is to enforce SSL/HTTPS communication between {{book.project.name}} and its clients and applications.
 This might seem like a no-brainer, but since {{book.project.name}} does not have SSL enabled by default, many naive admins
 might not realize they have to do this.

topics/threat/csrf.adoc

@@ -2,10 +2,10 @@
 === CSRF Attacks
 
 Cross-site request forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the
-web site trusts or has authenticated with(e.g., via HTTP redirects or HTML forms).  Any site that uses cookie based authentication is vulnerable for these types of attacks.
+web site trusts or has authenticated with(e.g., via HTTP redirects or HTML forms).  Any site that uses cookie based authentication is vulnerable to these types of attacks.
 These attacks are mitigated by matching a state cookie against a posted form or query parameter.
 
-OAuth 2.0 login specification requires that a state cookie be used and matched against a transmitted state parameter.
+The OAuth 2.0 login specification requires that a state cookie be used and matched against a transmitted state parameter.
 {{book.project.name}} fully implements this part of the specification so all logins are protected.
 
 The {{book.project.name}} Admin Console is a pure JavaScript/HTML5 application that makes REST calls to the backend {{book.project.name}} admin REST API.

topics/threat/redirect.adoc

@@ -4,6 +4,6 @@
 
 For the <<fake/../../sso-protocols/oidc.adoc#_oidc-auth-flows,Authorization Code Flow>>, if you register redirect URIs that
 are too general, then it would be possible for a rogue client to impersonate a different client that has a broader scope
-of access.  This could happen for instance if two clients live under the same domain.  So, its a good idea to make your
+of access.  This could happen for instance if two clients live under the same domain.  So, it's a good idea to make your
 registered redirect URIs as specific as feasible.
 

topics/threat/scope.adoc

@@ -1,7 +1,7 @@
 
 === Limiting Scope
 
-By default, each new client applications has an unlimited scope.  This means that every access token that is created
+By default, each new client application has an unlimited scope.  This means that every access token that is created
 for that client will contain all the permissions the user has.  If the client gets compromised and the access token
 is leaked, then each system that the user has permission to access is now also compromised.  It is highly suggested
 that you limit the roles an access token is assigned by using the <<fake/../../roles/client-scope.adoc#_client_scope, Scope menu>> for each client.

topics/threat/ssl.adoc

@@ -8,7 +8,7 @@ Once they have an access token they can do any operation that the token has been
 
 {{book.project.name}} has <<fake/../../realms/ssl.adoc#_ssl_modes,three modes for SSL/HTTPS>>.
 SSL can be hard to set up, so out of the box, {{book.project.name}} allows non-HTTPS communication over private IP addresses like
-localhost, 192.168.x.x, and other private IP addresses.
+localhost and 192.168.x.x.
 In production, you should make sure SSL is enabled and required across the board.
 
 On the adapter/client side, {{book.project.name}} allows you to turn off the SSL trust manager.