From 7d5a0696ccc642db0d14aae8677ecada40bf85d1 Mon Sep 17 00:00:00 2001 From: Arman Date: Thu, 2 Aug 2018 16:50:59 -0700 Subject: inital commit --- node_modules/hawk/.npmignore | 5 - node_modules/hawk/LICENSE | 28 -- node_modules/hawk/README.md | 637 ------------------------------ node_modules/hawk/client.js | 3 - node_modules/hawk/dist/browser.js | 793 -------------------------------------- node_modules/hawk/lib/browser.js | 653 ------------------------------- node_modules/hawk/lib/client.js | 394 ------------------- node_modules/hawk/lib/crypto.js | 128 ------ node_modules/hawk/lib/index.js | 17 - node_modules/hawk/lib/server.js | 550 -------------------------- node_modules/hawk/lib/utils.js | 186 --------- node_modules/hawk/package.json | 78 ---- 12 files changed, 3472 deletions(-) delete mode 100755 node_modules/hawk/.npmignore delete mode 100755 node_modules/hawk/LICENSE delete mode 100755 node_modules/hawk/README.md delete mode 100755 node_modules/hawk/client.js delete mode 100644 node_modules/hawk/dist/browser.js delete mode 100755 node_modules/hawk/lib/browser.js delete mode 100755 node_modules/hawk/lib/client.js delete mode 100755 node_modules/hawk/lib/crypto.js delete mode 100755 node_modules/hawk/lib/index.js delete mode 100755 node_modules/hawk/lib/server.js delete mode 100755 node_modules/hawk/lib/utils.js delete mode 100755 node_modules/hawk/package.json (limited to 'node_modules/hawk') diff --git a/node_modules/hawk/.npmignore b/node_modules/hawk/.npmignore deleted file mode 100755 index 7144676..0000000 --- a/node_modules/hawk/.npmignore +++ /dev/null @@ -1,5 +0,0 @@ -* -!lib/** -!dist/** -!client.js -!.npmignore diff --git a/node_modules/hawk/LICENSE b/node_modules/hawk/LICENSE deleted file mode 100755 index b43dce1..0000000 --- a/node_modules/hawk/LICENSE +++ /dev/null @@ -1,28 +0,0 @@ -Copyright (c) 2012-2017, Eran Hammer and Project contributors -All rights reserved. - -Redistribution and use in source and binary forms, with or without -modification, are permitted provided that the following conditions are met: - * Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - * Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in the - documentation and/or other materials provided with the distribution. - * The names of any contributors may not be used to endorse or promote - products derived from this software without specific prior written - permission. - -THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND -ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED -WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE -DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS AND CONTRIBUTORS BE LIABLE FOR ANY -DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES -(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; -LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND -ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS -SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - - * * * - -The complete list of contributors can be found at: https://github.com/hueniverse/hawk/graphs/contributors diff --git a/node_modules/hawk/README.md b/node_modules/hawk/README.md deleted file mode 100755 index fc5dd6d..0000000 --- a/node_modules/hawk/README.md +++ /dev/null @@ -1,637 +0,0 @@ -![hawk Logo](https://raw.github.com/hueniverse/hawk/master/images/hawk.png) - - **Hawk** is an HTTP authentication scheme using a message authentication code (MAC) algorithm to provide partial -HTTP request cryptographic verification. For more complex use cases such as access delegation, see [Oz](https://github.com/hueniverse/oz). - -Current version: **6.x** - -Note: 6.x, 5.x, 4.x, 3.x, and 2.x are the same exact protocol as 1.1. The version increments reflect changes in the node API. - -[![Build Status](https://travis-ci.org/hueniverse/hawk.svg?branch=master)](https://travis-ci.org/hueniverse/hawk) - -# Table of Content - -- [**Introduction**](#introduction) - - [Replay Protection](#replay-protection) - - [Usage Example](#usage-example) - - [Protocol Example](#protocol-example) - - [Payload Validation](#payload-validation) - - [Response Payload Validation](#response-payload-validation) - - [Browser Support and Considerations](#browser-support-and-considerations) -- [**Single URI Authorization**](#single-uri-authorization) - - [Usage Example](#bewit-usage-example) -- [**Security Considerations**](#security-considerations) - - [MAC Keys Transmission](#mac-keys-transmission) - - [Confidentiality of Requests](#confidentiality-of-requests) - - [Spoofing by Counterfeit Servers](#spoofing-by-counterfeit-servers) - - [Plaintext Storage of Credentials](#plaintext-storage-of-credentials) - - [Entropy of Keys](#entropy-of-keys) - - [Coverage Limitations](#coverage-limitations) - - [Future Time Manipulation](#future-time-manipulation) - - [Client Clock Poisoning](#client-clock-poisoning) - - [Bewit Limitations](#bewit-limitations) - - [Host Header Forgery](#host-header-forgery) -- [**Frequently Asked Questions**](#frequently-asked-questions) -- [**Implementations**](#implementations) -- [**Acknowledgements**](#acknowledgements) - -# Introduction - -**Hawk** is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with -partial cryptographic verification of the request and response, covering the HTTP method, request URI, host, -and optionally the request payload. - -Similar to the HTTP [Digest access authentication schemes](http://www.ietf.org/rfc/rfc2617.txt), **Hawk** uses a set of -client credentials which include an identifier (e.g. username) and key (e.g. password). Likewise, just as with the Digest scheme, -the key is never included in authenticated requests. Instead, it is used to calculate a request MAC value which is -included in its place. - -However, **Hawk** has several differences from Digest. In particular, while both use a nonce to limit the possibility of -replay attacks, in **Hawk** the client generates the nonce and uses it in combination with a timestamp, leading to less -"chattiness" (interaction with the server). - -Also unlike Digest, this scheme is not intended to protect the key itself (the password in Digest) because -the client and server must both have access to the key material in the clear. - -The primary design goals of this scheme are to: -* simplify and improve HTTP authentication for services that are unwilling or unable to deploy TLS for all resources, -* secure credentials against leakage (e.g., when the client uses some form of dynamic configuration to determine where - to send an authenticated request), and -* avoid the exposure of credentials sent to a malicious server over an unauthenticated secure channel due to client - failure to validate the server's identity as part of its TLS handshake. - -In addition, **Hawk** supports a method for granting third-parties temporary access to individual resources using -a query parameter called _bewit_ (in falconry, a leather strap used to attach a tracking device to the leg of a hawk). - -The **Hawk** scheme requires the establishment of a shared symmetric key between the client and the server, -which is beyond the scope of this module. Typically, the shared credentials are established via an initial -TLS-protected phase or derived from some other shared confidential information available to both the client -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 -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. - -The timestamp enables the server to restrict the validity period of the credentials where requests occurring afterwards -are rejected. It also removes the need for the server to retain an unbounded number of nonce values for future checks. -By default, **Hawk** uses a time window of 1 minute to allow for time skew between the client and server (which in -practice translates to a maximum of 2 minutes as the skew can be positive or negative). - -Using a timestamp requires the client's clock to be in sync with the server's clock. **Hawk** requires both the client -clock and the server clock to use NTP to ensure synchronization. However, given the limitations of some client types -(e.g. browsers) to deploy NTP, the server provides the client with its current time (in seconds precision) in response -to a bad timestamp. - -There is no expectation that the client will adjust its system clock to match the server (in fact, this would be a -potential attack vector). Instead, the client only uses the server's time to calculate an offset used only -for communications with that particular server. The protocol rewards clients with synchronized clocks by reducing -the number of round trips required to authenticate the first request. - - -## Usage Example - -Server code: - -```javascript -const Http = require('http'); -const Hawk = require('hawk'); - - -// Credentials lookup function - -const credentialsFunc = function (id, callback) { - - const credentials = { - key: 'werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn', - algorithm: 'sha256', - user: 'Steve' - }; - - return callback(null, credentials); -}; - -// Create HTTP server - -const handler = function (req, res) { - - // Authenticate incoming request - - Hawk.server.authenticate(req, credentialsFunc, {}, (err, credentials, artifacts) => { - - // Prepare response - - const payload = (!err ? `Hello ${credentials.user} ${artifacts.ext}` : 'Shoosh!'); - const headers = { 'Content-Type': 'text/plain' }; - - // Generate Server-Authorization response header - - const header = Hawk.server.header(credentials, artifacts, { payload, contentType: headers['Content-Type'] }); - headers['Server-Authorization'] = header; - - // Send the response back - - res.writeHead(!err ? 200 : 401, headers); - res.end(payload); - }); -}; - -// Start server - -Http.createServer(handler).listen(8000, 'example.com'); -``` - -Client code: - -```javascript -const Request = require('request'); -const Hawk = require('hawk'); - - -// Client credentials - -const credentials = { - id: 'dh37fgj492je', - key: 'werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn', - algorithm: 'sha256' -} - -// Request options - -const requestOptions = { - uri: 'http://example.com:8000/resource/1?b=1&a=2', - method: 'GET', - headers: {} -}; - -// Generate Authorization request header - -const header = Hawk.client.header('http://example.com:8000/resource/1?b=1&a=2', 'GET', { credentials: credentials, ext: 'some-app-data' }); -requestOptions.headers.Authorization = header.field; - -// Send authenticated request - -Request(requestOptions, function (error, response, body) { - - // Authenticate the server's response - - const isValid = Hawk.client.authenticate(response, credentials, header.artifacts, { payload: body }); - - // Output results - - console.log(`${response.statusCode}: ${body}` + (isValid ? ' (valid)' : ' (invalid)')); -}); -``` - -**Hawk** utilized the [**SNTP**](https://github.com/hueniverse/sntp) module for time sync management. By default, the local -machine time is used. To automatically retrieve and synchronize the clock within the application, use the SNTP 'start()' method. - -```javascript -Hawk.sntp.start(); -``` - - -## Protocol Example - -The client attempts to access a protected resource without authentication, sending the following HTTP request to -the resource server: - -``` -GET /resource/1?b=1&a=2 HTTP/1.1 -Host: example.com:8000 -``` - -The resource server returns an authentication challenge. - -``` -HTTP/1.1 401 Unauthorized -WWW-Authenticate: Hawk -``` - -The client has previously obtained a set of **Hawk** credentials for accessing resources on the "`http://example.com/`" -server. The **Hawk** credentials issued to the client include the following attributes: - -* Key identifier: `dh37fgj492je` -* Key: `werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn` -* Algorithm: `hmac sha256` -* Hash: `6R4rV5iE+NPoym+WwjeHzjAGXUtLNIxmo1vpMofpLAE=` - -The client generates the authentication header by calculating a timestamp (e.g. the number of seconds since January 1, -1970 00:00:00 GMT), generating a nonce, and constructing the normalized request string (each value followed by a newline -character): - -``` -hawk.1.header -1353832234 -j4h3g2 -GET -/resource/1?b=1&a=2 -example.com -8000 - -some-app-ext-data - -``` - -The request MAC is calculated using HMAC with the specified hash algorithm "`sha256`" and the key over the normalized request string. -The result is base64-encoded to produce the request MAC: - -``` -6R4rV5iE+NPoym+WwjeHzjAGXUtLNIxmo1vpMofpLAE= -``` - -The client includes the **Hawk** key identifier, timestamp, nonce, application specific data, and request MAC with the request using -the HTTP `Authorization` request header field: - -``` -GET /resource/1?b=1&a=2 HTTP/1.1 -Host: example.com:8000 -Authorization: Hawk id="dh37fgj492je", ts="1353832234", nonce="j4h3g2", ext="some-app-ext-data", mac="6R4rV5iE+NPoym+WwjeHzjAGXUtLNIxmo1vpMofpLAE=" -``` - -The server validates the request by calculating the request MAC again based on the request received and verifies the validity -and scope of the **Hawk** credentials. If valid, the server responds with the requested resource. - - -### Payload Validation - -**Hawk** provides optional payload validation. When generating the authentication header, the client calculates a payload hash -using the specified hash algorithm. The hash is calculated over the concatenated value of (each followed by a newline character): -* `hawk.1.payload` -* the content-type in lowercase, without any parameters (e.g. `application/json`) -* the request payload prior to any content encoding (the exact representation requirements should be specified by the server for payloads other than simple single-part ascii to ensure interoperability) - -For example: - -* Payload: `Thank you for flying Hawk` -* Content Type: `text/plain` -* Algorithm: `sha256` -* Hash: `Yi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY=` - -Results in the following input to the payload hash function (newline terminated values): - -``` -hawk.1.payload -text/plain -Thank you for flying Hawk - -``` - -Which produces the following hash value: - -``` -Yi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY= -``` - -The client constructs the normalized request string (newline terminated values): - -``` -hawk.1.header -1353832234 -j4h3g2 -POST -/resource/1?a=1&b=2 -example.com -8000 -Yi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY= -some-app-ext-data - -``` - -Then calculates the request MAC and includes the **Hawk** key identifier, timestamp, nonce, payload hash, application specific data, -and request MAC, with the request using the HTTP `Authorization` request header field: - -``` -POST /resource/1?a=1&b=2 HTTP/1.1 -Host: example.com:8000 -Authorization: Hawk id="dh37fgj492je", ts="1353832234", nonce="j4h3g2", hash="Yi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY=", ext="some-app-ext-data", mac="aSe1DERmZuRl3pI36/9BdZmnErTw3sNzOOAUlfeKjVw=" -``` - -It is up to the server if and when it validates the payload for any given request, based solely on its security policy -and the nature of the data included. - -If the payload is available at the time of authentication, the server uses the hash value provided by the client to construct -the normalized string and validates the MAC. If the MAC is valid, the server calculates the payload hash and compares the value -with the provided payload hash in the header. In many cases, checking the MAC first is faster than calculating the payload hash. - -However, if the payload is not available at authentication time (e.g. too large to fit in memory, streamed elsewhere, or processed -at a different stage in the application), the server may choose to defer payload validation for later by retaining the hash value -provided by the client after validating the MAC. - -It is important to note that MAC validation does not mean the hash value provided by the client is valid, only that the value -included in the header was not modified. Without calculating the payload hash on the server and comparing it to the value provided -by the client, the payload may be modified by an attacker. - - -## Response Payload Validation - -**Hawk** provides partial response payload validation. The server includes the `Server-Authorization` response header which enables the -client to authenticate the response and ensure it is talking to the right server. **Hawk** defines the HTTP `Server-Authorization` header -as a response header using the exact same syntax as the `Authorization` request header field. - -The header is constructed using the same process as the client's request header. The server uses the same credentials and other -artifacts provided by the client to constructs the normalized request string. The `ext` and `hash` values are replaced with -new values based on the server response. The rest as identical to those used by the client. - -The result MAC digest is included with the optional `hash` and `ext` values: - -``` -Server-Authorization: Hawk mac="XIJRsMl/4oL+nn+vKoeVZPdCHXB4yJkNnBbTbHFZUYE=", hash="f9cDF/TDm7TkYRLnGwRMfeDzT6LixQVLvrIKhh0vgmM=", ext="response-specific" -``` - - -## Browser Support and Considerations - -A browser script is provided for including using a `