diff options
Diffstat (limited to 'deps/npm/node_modules/request/node_modules/hawk/README.md')
| -rwxr-xr-x | deps/npm/node_modules/request/node_modules/hawk/README.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/deps/npm/node_modules/request/node_modules/hawk/README.md b/deps/npm/node_modules/request/node_modules/hawk/README.md index 4aff23f3a3..63725034fc 100755 --- a/deps/npm/node_modules/request/node_modules/hawk/README.md +++ b/deps/npm/node_modules/request/node_modules/hawk/README.md @@ -75,12 +75,12 @@ and the server. ## Replay Protection -Without replay protection, an attacker can use a compromised (but otherwise valid and authenticated) request more -than once, gaining access to a protected resource. To mitigate this, clients include both a nonce and a timestamp when +Without replay protection, an attacker can use a compromised (but otherwise valid and authenticated) request more +than once, gaining access to a protected resource. To mitigate this, clients include both a nonce and a timestamp when making requests. This gives the server enough information to prevent replay attacks. The nonce is generated by the client, and is a string unique across all requests with the same timestamp and -key identifier combination. +key identifier combination. The timestamp enables the server to restrict the validity period of the credentials where requests occuring afterwards are rejected. It also removes the need for the server to retain an unbounded number of nonce values for future checks. @@ -373,7 +373,7 @@ and for a finite period of time. Both the client and server can issue bewit cred credentials as the client to maintain clear traceability as to who issued which credentials. In order to simplify implementation, bewit credentials do not support single-use policy and can be replayed multiple times within -the granted access timeframe. +the granted access timeframe. ## Bewit Usage Example @@ -496,7 +496,7 @@ which can often affect how the request body is interpreted by the server. If the or value of such headers, an attacker can manipulate the request headers without being detected. Implementers should use the `ext` feature to pass application-specific information via the `Authorization` header which is protected by the request MAC. -The response authentication, when performed, only covers the response payload, content-type, and the request information +The response authentication, when performed, only covers the response payload, content-type, and the request information provided by the client in it's request (method, resource, timestamp, nonce, etc.). It does not cover the HTTP status code or any other response header field (e.g. Location) which can affect the client's behaviour. |