diff --git a/topics/threat/brute-force.adoc b/topics/threat/brute-force.adoc index 85f1016703..e73d060453 100644 --- a/topics/threat/brute-force.adoc +++ b/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 -account that are too quick for a human to initiate the account will be disabled then. This is controlled by the +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. 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://www.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 <> 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). diff --git a/topics/threat/clickjacking.adoc b/topics/threat/clickjacking.adoc index 2044bcc455..e2da39499c 100644 --- a/topics/threat/clickjacking.adoc +++ b/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 -specifically 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 -with these headers. +By default, every response by {{book.project.name}} sets some specific browser headers that can prevent this from happening. +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. 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. diff --git a/topics/threat/compromised-codes.adoc b/topics/threat/compromised-codes.adoc index 888df056c3..75f08b9458 100644 --- a/topics/threat/compromised-codes.adoc +++ b/topics/threat/compromised-codes.adoc @@ -1,7 +1,7 @@ === Compromised Access Codes -For the <>, t would be very hard for an attacker to compromise {{book.project.name}} access codes. +For the <>, 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 <>. diff --git a/topics/threat/compromised-tokens.adoc b/topics/threat/compromised-tokens.adoc index 3df91849db..e436cbdd45 100644 --- a/topics/threat/compromised-tokens.adoc +++ b/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. diff --git a/topics/threat/csrf.adoc b/topics/threat/csrf.adoc index 99fd212039..12443128d8 100644 --- a/topics/threat/csrf.adoc +++ b/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. diff --git a/topics/threat/redirect.adoc b/topics/threat/redirect.adoc index 2102035aa8..97e4878f82 100644 --- a/topics/threat/redirect.adoc +++ b/topics/threat/redirect.adoc @@ -4,6 +4,6 @@ For the <>, 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. diff --git a/topics/threat/scope.adoc b/topics/threat/scope.adoc index 3e69e6527e..b228c92ec1 100644 --- a/topics/threat/scope.adoc +++ b/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 <> for each client.