embeditor-rails 2.0.0.beta → 2.0.0

data/lib/node_modules/npm/node_modules/request/node_modules/hawk/node_modules/sntp/package.json

@@ -1,48 +0,0 @@
-{
-  "name": "sntp",
-  "description": "SNTP Client",
-  "version": "0.2.4",
-  "author": {
-    "name": "Eran Hammer",
-    "email": "eran@hueniverse.com",
-    "url": "http://hueniverse.com"
-  },
-  "contributors": [],
-  "repository": {
-    "type": "git",
-    "url": "git://github.com/hueniverse/sntp"
-  },
-  "main": "index",
-  "keywords": [
-    "sntp",
-    "ntp",
-    "time"
-  ],
-  "engines": {
-    "node": ">=0.8.0"
-  },
-  "dependencies": {
-    "hoek": "0.9.x"
-  },
-  "devDependencies": {
-    "lab": "0.1.x",
-    "complexity-report": "0.x.x"
-  },
-  "scripts": {
-    "test": "make test-cov"
-  },
-  "licenses": [
-    {
-      "type": "BSD",
-      "url": "http://github.com/hueniverse/sntp/raw/master/LICENSE"
-    }
-  ],
-  "readme": "# sntp\n\nAn SNTP v4 client (RFC4330) for node. Simpy connects to the NTP or SNTP server requested and returns the server time\nalong with the roundtrip duration and clock offset. To adjust the local time to the NTP time, add the returned `t` offset\nto the local time.\n\n[![Build Status](https://secure.travis-ci.org/hueniverse/sntp.png)](http://travis-ci.org/hueniverse/sntp)\n\n# Usage\n\n```javascript\nvar Sntp = require('sntp');\n\n// All options are optional\n\nvar options = {\n    host: 'nist1-sj.ustiming.org',  // Defaults to pool.ntp.org\n    port: 123,                      // Defaults to 123 (NTP)\n    resolveReference: true,         // Default to false (not resolving)\n    timeout: 1000                   // Defaults to zero (no timeout)\n};\n\n// Request server time\n\nSntp.time(options, function (err, time) {\n\n    if (err) {\n        console.log('Failed: ' + err.message);\n        process.exit(1);\n    }\n\n    console.log('Local clock is off by: ' + time.t + ' milliseconds');\n    process.exit(0);\n});\n```\n\nIf an application needs to maintain continuous time synchronization, the module provides a stateful method for\nquerying the current offset only when the last one is too old (defaults to daily).\n\n```javascript\n// Request offset once\n\nSntp.offset(function (err, offset) {\n\n    console.log(offset);                    // New (served fresh)\n\n    // Request offset again\n\n    Sntp.offset(function (err, offset) {\n\n        console.log(offset);                // Identical (served from cache)\n    });\n});\n```\n\nTo set a background offset refresh, start the interval and use the provided now() method. If for any reason the\nclient fails to obtain an up-to-date offset, the current system clock is used.\n\n```javascript\nvar before = Sntp.now();                    // System time without offset\n\nSntp.start(function () {\n\n    var now = Sntp.now();                   // With offset\n    Sntp.stop();\n});\n```\n\n",
-  "readmeFilename": "README.md",
-  "bugs": {
-    "url": "https://github.com/hueniverse/sntp/issues"
-  },
-  "homepage": "https://github.com/hueniverse/sntp",
-  "_id": "sntp@0.2.4",
-  "_from": "sntp@0.2.x"
-}

data/lib/node_modules/npm/node_modules/request/node_modules/hawk/package.json

@@ -1,53 +0,0 @@
-{
-  "name": "hawk",
-  "description": "HTTP Hawk Authentication Scheme",
-  "version": "1.0.0",
-  "author": {
-    "name": "Eran Hammer",
-    "email": "eran@hueniverse.com",
-    "url": "http://hueniverse.com"
-  },
-  "contributors": [],
-  "repository": {
-    "type": "git",
-    "url": "git://github.com/hueniverse/hawk"
-  },
-  "main": "index",
-  "keywords": [
-    "http",
-    "authentication",
-    "scheme",
-    "hawk"
-  ],
-  "engines": {
-    "node": ">=0.8.0"
-  },
-  "dependencies": {
-    "hoek": "0.9.x",
-    "boom": "0.4.x",
-    "cryptiles": "0.2.x",
-    "sntp": "0.2.x"
-  },
-  "devDependencies": {
-    "lab": "0.1.x",
-    "complexity-report": "0.x.x",
-    "localStorage": "1.0.x"
-  },
-  "scripts": {
-    "test": "make test-cov"
-  },
-  "licenses": [
-    {
-      "type": "BSD",
-      "url": "http://github.com/hueniverse/hawk/raw/master/LICENSE"
-    }
-  ],
-  "readme": "![hawk Logo](https://raw.github.com/hueniverse/hawk/master/images/hawk.png)\n\n<img align=\"right\" src=\"https://raw.github.com/hueniverse/hawk/master/images/logo.png\" /> **Hawk** is an HTTP authentication scheme using a message authentication code (MAC) algorithm to provide partial\nHTTP request cryptographic verification. For more complex use cases such as access delegation, see [Oz](https://github.com/hueniverse/oz).\n\nCurrent version: **1.0**\n\n[![Build Status](https://secure.travis-ci.org/hueniverse/hawk.png)](http://travis-ci.org/hueniverse/hawk)\n\n# Table of Content\n\n- [**Introduction**](#introduction)\n  - [Replay Protection](#replay-protection)\n  - [Usage Example](#usage-example)\n  - [Protocol Example](#protocol-example)\n    - [Payload Validation](#payload-validation)\n    - [Response Payload Validation](#response-payload-validation)\n  - [Browser Support and Considerations](#browser-support-and-considerations)\n<p></p>\n- [**Single URI Authorization**](#single-uri-authorization)\n  - [Usage Example](#bewit-usage-example)\n<p></p>\n- [**Security Considerations**](#security-considerations)\n  - [MAC Keys Transmission](#mac-keys-transmission)\n  - [Confidentiality of Requests](#confidentiality-of-requests)\n  - [Spoofing by Counterfeit Servers](#spoofing-by-counterfeit-servers)\n  - [Plaintext Storage of Credentials](#plaintext-storage-of-credentials)\n  - [Entropy of Keys](#entropy-of-keys)\n  - [Coverage Limitations](#coverage-limitations)\n  - [Future Time Manipulation](#future-time-manipulation)\n  - [Client Clock Poisoning](#client-clock-poisoning)\n  - [Bewit Limitations](#bewit-limitations)\n  - [Host Header Forgery](#host-header-forgery)\n<p></p>\n- [**Frequently Asked Questions**](#frequently-asked-questions)\n<p></p>\n- [**Acknowledgements**](#acknowledgements)\n\n# Introduction\n\n**Hawk** is an HTTP authentication scheme providing mechanisms for making authenticated HTTP requests with\npartial cryptographic verification of the request and response, covering the HTTP method, request URI, host,\nand optionally the request payload.\n\nSimilar to the HTTP [Digest access authentication schemes](http://www.ietf.org/rfc/rfc2617.txt), **Hawk** uses a set of\nclient credentials which include an identifier (e.g. username) and key (e.g. password). Likewise, just as with the Digest scheme,\nthe key is never included in authenticated requests. Instead, it is used to calculate a request MAC value which is\nincluded in its place.\n\nHowever, **Hawk** has several differences from Digest. In particular, while both use a nonce to limit the possibility of\nreplay attacks, in **Hawk** the client generates the nonce and uses it in combination with a timestamp, leading to less\n\"chattiness\" (interaction with the server).\n\nAlso unlike Digest, this scheme is not intended to protect the key itself (the password in Digest) because\nthe client and server must both have access to the key material in the clear.\n\nThe primary design goals of this scheme are to:\n* simplify and improve HTTP authentication for services that are unwilling or unable to deploy TLS for all resources,\n* secure credentials against leakage (e.g., when the client uses some form of dynamic configuration to determine where\n  to send an authenticated request), and\n* avoid the exposure of credentials sent to a malicious server over an unauthenticated secure channel due to client\n  failure to validate the server's identity as part of its TLS handshake.\n\nIn addition, **Hawk** supports a method for granting third-parties temporary access to individual resources using\na query parameter called _bewit_ (in falconry, a leather strap used to attach a tracking device to the leg of a hawk).\n\nThe **Hawk** scheme requires the establishment of a shared symmetric key between the client and the server,\nwhich is beyond the scope of this module. Typically, the shared credentials are established via an initial\nTLS-protected phase or derived from some other shared confidential information available to both the client\nand the server.\n\n\n## Replay Protection\n\nWithout replay protection, an attacker can use a compromised (but otherwise valid and authenticated) request more \nthan once, gaining access to a protected resource. To mitigate this, clients include both a nonce and a timestamp when \nmaking requests. This gives the server enough information to prevent replay attacks.\n\nThe nonce is generated by the client, and is a string unique across all requests with the same timestamp and\nkey identifier combination. \n\nThe timestamp enables the server to restrict the validity period of the credentials where requests occuring afterwards\nare rejected. It also removes the need for the server to retain an unbounded number of nonce values for future checks.\nBy default, **Hawk** uses a time window of 1 minute to allow for time skew between the client and server (which in\npractice translates to a maximum of 2 minutes as the skew can be positive or negative).\n\nUsing a timestamp requires the client's clock to be in sync with the server's clock. **Hawk** requires both the client\nclock and the server clock to use NTP to ensure synchronization. However, given the limitations of some client types\n(e.g. browsers) to deploy NTP, the server provides the client with its current time (in seconds precision) in response\nto a bad timestamp.\n\nThere is no expectation that the client will adjust its system clock to match the server (in fact, this would be a\npotential attack vector). Instead, the client only uses the server's time to calculate an offset used only\nfor communications with that particular server. The protocol rewards clients with synchronized clocks by reducing\nthe number of round trips required to authenticate the first request.\n\n\n## Usage Example\n\nServer code:\n\n```javascript\nvar Http = require('http');\nvar Hawk = require('hawk');\n\n\n// Credentials lookup function\n\nvar credentialsFunc = function (id, callback) {\n\n    var credentials = {\n        key: 'werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn',\n        algorithm: 'sha256',\n        user: 'Steve'\n    };\n\n    return callback(null, credentials);\n};\n\n// Create HTTP server\n\nvar handler = function (req, res) {\n\n    // Authenticate incoming request\n\n    Hawk.server.authenticate(req, credentialsFunc, {}, function (err, credentials, artifacts) {\n\n        // Prepare response\n\n        var payload = (!err ? 'Hello ' + credentials.user + ' ' + artifacts.ext : 'Shoosh!');\n        var headers = { 'Content-Type': 'text/plain' };\n\n        // Generate Server-Authorization response header\n\n        var header = Hawk.server.header(credentials, artifacts, { payload: payload, contentType: headers['Content-Type'] });\n        headers['Server-Authorization'] = header;\n\n        // Send the response back\n\n        res.writeHead(!err ? 200 : 401, headers);\n        res.end(payload);\n    });\n};\n\n// Start server\n\nHttp.createServer(handler).listen(8000, 'example.com');\n```\n\nClient code:\n\n```javascript\nvar Request = require('request');\nvar Hawk = require('hawk');\n\n\n// Client credentials\n\nvar credentials = {\n    id: 'dh37fgj492je',\n    key: 'werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn',\n    algorithm: 'sha256'\n}\n\n// Request options\n\nvar requestOptions = {\n    uri: 'http://example.com:8000/resource/1?b=1&a=2',\n    method: 'GET',\n    headers: {}\n};\n\n// Generate Authorization request header\n\nvar header = Hawk.client.header('http://example.com:8000/resource/1?b=1&a=2', 'GET', { credentials: credentials, ext: 'some-app-data' });\nrequestOptions.headers.Authorization = header.field;\n\n// Send authenticated request\n\nRequest(requestOptions, function (error, response, body) {\n\n    // Authenticate the server's response\n\n    var isValid = Hawk.client.authenticate(response, credentials, header.artifacts, { payload: body });\n\n    // Output results\n\n    console.log(response.statusCode + ': ' + body + (isValid ? ' (valid)' : ' (invalid)'));\n});\n```\n\n**Hawk** utilized the [**SNTP**](https://github.com/hueniverse/sntp) module for time sync management. By default, the local\nmachine time is used. To automatically retrieve and synchronice the clock within the application, use the SNTP 'start()' method.\n\n```javascript\nHawk.sntp.start();\n```\n\n\n## Protocol Example\n\nThe client attempts to access a protected resource without authentication, sending the following HTTP request to\nthe resource server:\n\n```\nGET /resource/1?b=1&a=2 HTTP/1.1\nHost: example.com:8000\n```\n\nThe resource server returns an authentication challenge.\n\n```\nHTTP/1.1 401 Unauthorized\nWWW-Authenticate: Hawk\n```\n\nThe client has previously obtained a set of **Hawk** credentials for accessing resources on the \"http://example.com/\"\nserver. The **Hawk** credentials issued to the client include the following attributes:\n\n* Key identifier: dh37fgj492je\n* Key: werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn\n* Algorithm: sha256\n\nThe client generates the authentication header by calculating a timestamp (e.g. the number of seconds since January 1,\n1970 00:00:00 GMT), generating a nonce, and constructing the normalized request string (each value followed by a newline\ncharacter):\n\n```\nhawk.1.header\n1353832234\nj4h3g2\nGET\n/resource/1?b=1&a=2\nexample.com\n8000\n\nsome-app-ext-data\n\n```\n\nThe request MAC is calculated using HMAC with the specified hash algorithm \"sha256\" and the key over the normalized request string.\nThe result is base64-encoded to produce the request MAC:\n\n```\n6R4rV5iE+NPoym+WwjeHzjAGXUtLNIxmo1vpMofpLAE=\n```\n\nThe client includes the **Hawk** key identifier, timestamp, nonce, application specific data, and request MAC with the request using\nthe HTTP `Authorization` request header field:\n\n```\nGET /resource/1?b=1&a=2 HTTP/1.1\nHost: example.com:8000\nAuthorization: Hawk id=\"dh37fgj492je\", ts=\"1353832234\", nonce=\"j4h3g2\", ext=\"some-app-ext-data\", mac=\"6R4rV5iE+NPoym+WwjeHzjAGXUtLNIxmo1vpMofpLAE=\"\n```\n\nThe server validates the request by calculating the request MAC again based on the request received and verifies the validity\nand scope of the **Hawk** credentials. If valid, the server responds with the requested resource.\n\n\n### Payload Validation\n\n**Hawk** provides optional payload validation. When generating the authentication header, the client calculates a payload hash\nusing the specified hash algorithm. The hash is calculated over the concatenated value of (each followed by a newline character):\n* `hawk.1.payload`\n* the content-type in lowercase, without any parameters (e.g. `application/json`)\n* 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)\n\nFor example:\n\n* Payload: `Thank you for flying Hawk`\n* Content Type: `text/plain`\n* Hash (sha256): `Yi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY=`\n\nResults in the following input to the payload hash function (newline terminated values):\n\n```\nhawk.1.payload\ntext/plain\nThank you for flying Hawk\n\n```\n\nWhich produces the following hash value:\n\n```\nYi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY=\n```\n\nThe client constructs the normalized request string (newline terminated values):\n\n```\nhawk.1.header\n1353832234\nj4h3g2\nPOST\n/resource/1?a=1&b=2\nexample.com\n8000\nYi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY=\nsome-app-ext-data\n\n```\n\nThen calculates the request MAC and includes the **Hawk** key identifier, timestamp, nonce, payload hash, application specific data,\nand request MAC, with the request using the HTTP `Authorization` request header field:\n\n```\nPOST /resource/1?a=1&b=2 HTTP/1.1\nHost: example.com:8000\nAuthorization: Hawk id=\"dh37fgj492je\", ts=\"1353832234\", nonce=\"j4h3g2\", hash=\"Yi9LfIIFRtBEPt74PVmbTF/xVAwPn7ub15ePICfgnuY=\", ext=\"some-app-ext-data\", mac=\"aSe1DERmZuRl3pI36/9BdZmnErTw3sNzOOAUlfeKjVw=\"\n```\n\nIt is up to the server if and when it validates the payload for any given request, based solely on it's security policy\nand the nature of the data included.\n\nIf the payload is available at the time of authentication, the server uses the hash value provided by the client to construct\nthe normalized string and validates the MAC. If the MAC is valid, the server calculates the payload hash and compares the value\nwith the provided payload hash in the header. In many cases, checking the MAC first is faster than calculating the payload hash.\n\nHowever, if the payload is not available at authentication time (e.g. too large to fit in memory, streamed elsewhere, or processed\nat a different stage in the application), the server may choose to defer payload validation for later by retaining the hash value\nprovided by the client after validating the MAC.\n\nIt is important to note that MAC validation does not mean the hash value provided by the client is valid, only that the value\nincluded in the header was not modified. Without calculating the payload hash on the server and comparing it to the value provided\nby the client, the payload may be modified by an attacker.\n\n\n## Response Payload Validation\n\n**Hawk** provides partial response payload validation. The server includes the `Server-Authorization` response header which enables the\nclient to authenticate the response and ensure it is talking to the right server. **Hawk** defines the HTTP `Server-Authorization` header\nas a response header using the exact same syntax as the `Authorization` request header field.\n\nThe header is contructed using the same process as the client's request header. The server uses the same credentials and other\nartifacts provided by the client to constructs the normalized request string. The `ext` and `hash` values are replaced with\nnew values based on the server response. The rest as identical to those used by the client.\n\nThe result MAC digest is included with the optional `hash` and `ext` values:\n\n```\nServer-Authorization: Hawk mac=\"XIJRsMl/4oL+nn+vKoeVZPdCHXB4yJkNnBbTbHFZUYE=\", hash=\"f9cDF/TDm7TkYRLnGwRMfeDzT6LixQVLvrIKhh0vgmM=\", ext=\"response-specific\"\n```\n\n\n## Browser Support and Considerations\n\nA browser script is provided for including using a `<script>` tag in [lib/browser.js](/lib/browser.js).\n\n**Hawk** relies on the _Server-Authorization_ and _WWW-Authenticate_ headers in its response to communicate with the client.\nTherefore, in case of CORS requests, it is important to consider sending _Access-Control-Expose-Headers_ with the value\n_\"WWW-Authenticate, Server-Authorization\"_ on each response from your server. As explained in the\n[specifications](http://www.w3.org/TR/cors/#access-control-expose-headers-response-header), it will indicate that these headers\ncan safely be accessed by the client (using getResponseHeader() on the XmlHttpRequest object). Otherwise you will be met with a\n[\"simple response header\"](http://www.w3.org/TR/cors/#simple-response-header) which excludes these fields and would prevent the\nHawk client from authenticating the requests.You can read more about the why and how in this\n[article](http://www.html5rocks.com/en/tutorials/cors/#toc-adding-cors-support-to-the-server)\n\n\n# Single URI Authorization\n\nThere are cases in which limited and short-term access to a protected resource is granted to a third party which does not\nhave access to the shared credentials. For example, displaying a protected image on a web page accessed by anyone. **Hawk**\nprovides limited support for such URIs in the form of a _bewit_ - a URI query parameter appended to the request URI which contains\nthe necessary credentials to authenticate the request.\n\nBecause of the significant security risks involved in issuing such access, bewit usage is purposely limited only to GET requests\nand for a finite period of time. Both the client and server can issue bewit credentials, however, the server should not use the same\ncredentials as the client to maintain clear traceability as to who issued which credentials.\n\nIn order to simplify implementation, bewit credentials do not support single-use policy and can be replayed multiple times within\nthe granted access timeframe. \n\n\n## Bewit Usage Example\n\nServer code:\n\n```javascript\nvar Http = require('http');\nvar Hawk = require('hawk');\n\n\n// Credentials lookup function\n\nvar credentialsFunc = function (id, callback) {\n\n    var credentials = {\n        key: 'werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn',\n        algorithm: 'sha256'\n    };\n\n    return callback(null, credentials);\n};\n\n// Create HTTP server\n\nvar handler = function (req, res) {\n\n    Hawk.uri.authenticate(req, credentialsFunc, {}, function (err, credentials, attributes) {\n\n        res.writeHead(!err ? 200 : 401, { 'Content-Type': 'text/plain' });\n        res.end(!err ? 'Access granted' : 'Shoosh!');\n    });\n};\n\nHttp.createServer(handler).listen(8000, 'example.com');\n```\n\nBewit code generation:\n\n```javascript\nvar Request = require('request');\nvar Hawk = require('hawk');\n\n\n// Client credentials\n\nvar credentials = {\n    id: 'dh37fgj492je',\n    key: 'werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn',\n    algorithm: 'sha256'\n}\n\n// Generate bewit\n\nvar duration = 60 * 5;      // 5 Minutes\nvar bewit = Hawk.uri.getBewit('http://example.com:8080/resource/1?b=1&a=2', { credentials: credentials, ttlSec: duration, ext: 'some-app-data' });\nvar uri = 'http://example.com:8000/resource/1?b=1&a=2' + '&bewit=' + bewit;\n```\n\n\n# Security Considerations\n\nThe greatest sources of security risks are usually found not in **Hawk** but in the policies and procedures surrounding its use.\nImplementers are strongly encouraged to assess how this module addresses their security requirements. This section includes\nan incomplete list of security considerations that must be reviewed and understood before deploying **Hawk** on the server.\nMany of the protections provided in **Hawk** depends on whether and how they are used.\n\n### MAC Keys Transmission\n\n**Hawk** does not provide any mechanism for obtaining or transmitting the set of shared credentials required. Any mechanism used\nto obtain **Hawk** credentials must ensure that these transmissions are protected using transport-layer mechanisms such as TLS.\n\n### Confidentiality of Requests\n\nWhile **Hawk** provides a mechanism for verifying the integrity of HTTP requests, it provides no guarantee of request\nconfidentiality. Unless other precautions are taken, eavesdroppers will have full access to the request content. Servers should\ncarefully consider the types of data likely to be sent as part of such requests, and employ transport-layer security mechanisms\nto protect sensitive resources.\n\n### Spoofing by Counterfeit Servers\n\n**Hawk** provides limited verification of the server authenticity. When receiving a response back from the server, the server\nmay choose to include a response `Server-Authorization` header which the client can use to verify the response. However, it is up to\nthe server to determine when such measure is included, to up to the client to enforce that policy.\n\nA hostile party could take advantage of this by intercepting the client's requests and returning misleading or otherwise\nincorrect responses. Service providers should consider such attacks when developing services using this protocol, and should\nrequire transport-layer security for any requests where the authenticity of the resource server or of server responses is an issue.\n\n### Plaintext Storage of Credentials\n\nThe **Hawk** key functions the same way passwords do in traditional authentication systems. In order to compute the request MAC,\nthe server must have access to the key in plaintext form. This is in contrast, for example, to modern operating systems, which\nstore only a one-way hash of user credentials.\n\nIf an attacker were to gain access to these keys - or worse, to the server's database of all such keys - he or she would be able\nto perform any action on behalf of any resource owner. Accordingly, it is critical that servers protect these keys from unauthorized\naccess.\n\n### Entropy of Keys\n\nUnless a transport-layer security protocol is used, eavesdroppers will have full access to authenticated requests and request\nMAC values, and will thus be able to mount offline brute-force attacks to recover the key used. Servers should be careful to\nassign keys which are long enough, and random enough, to resist such attacks for at least the length of time that the **Hawk**\ncredentials are valid.\n\nFor example, if the credentials are valid for two weeks, servers should ensure that it is not possible to mount a brute force\nattack that recovers the key in less than two weeks. Of course, servers are urged to err on the side of caution, and use the\nlongest key reasonable.\n\nIt is equally important that the pseudo-random number generator (PRNG) used to generate these keys be of sufficiently high\nquality. Many PRNG implementations generate number sequences that may appear to be random, but which nevertheless exhibit\npatterns or other weaknesses which make cryptanalysis or brute force attacks easier. Implementers should be careful to use\ncryptographically secure PRNGs to avoid these problems.\n\n### Coverage Limitations\n\nThe request MAC only covers the HTTP `Host` header and optionally the `Content-Type` header. It does not cover any other headers\nwhich can often affect how the request body is interpreted by the server. If the server behavior is influenced by the presence\nor value of such headers, an attacker can manipulate the request headers without being detected. Implementers should use the\n`ext` feature to pass application-specific information via the `Authorization` header which is protected by the request MAC.\n\nThe response authentication, when performed, only covers the response payload, content-type, and the request information \nprovided by the client in it's request (method, resource, timestamp, nonce, etc.). It does not cover the HTTP status code or\nany other response header field (e.g. Location) which can affect the client's behaviour.\n\n### Future Time Manipulation\n\nThe protocol relies on a clock sync between the client and server. To accomplish this, the server informs the client of its\ncurrent time when an invalid timestamp is received.\n\nIf an attacker is able to manipulate this information and cause the client to use an incorrect time, it would be able to cause\nthe client to generate authenticated requests using time in the future. Such requests will fail when sent by the client, and will\nnot likely leave a trace on the server (given the common implementation of nonce, if at all enforced). The attacker will then\nbe able to replay the request at the correct time without detection.\n\nThe client must only use the time information provided by the server if:\n* it was delivered over a TLS connection and the server identity has been verified, or\n* the `tsm` MAC digest calculated using the same client credentials over the timestamp has been verified.\n\n### Client Clock Poisoning\n\nWhen receiving a request with a bad timestamp, the server provides the client with its current time. The client must never use\nthe time received from the server to adjust its own clock, and must only use it to calculate an offset for communicating with\nthat particular server.\n\n### Bewit Limitations\n\nSpecial care must be taken when issuing bewit credentials to third parties. Bewit credentials are valid until expiration and cannot\nbe revoked or limited without using other means. Whatever resource they grant access to will be completely exposed to anyone with\naccess to the bewit credentials which act as bearer credentials for that particular resource. While bewit usage is limited to GET\nrequests only and therefore cannot be used to perform transactions or change server state, it can still be used to expose private\nand sensitive information.\n\n### Host Header Forgery\n\nHawk validates the incoming request MAC against the incoming HTTP Host header. However, unless the optional `host` and `port`\noptions are used with `server.authenticate()`, a malicous client can mint new host names pointing to the server's IP address and\nuse that to craft an attack by sending a valid request that's meant for another hostname than the one used by the server. Server\nimplementors must manually verify that the host header received matches their expectation (or use the options mentioned above).\n\n# Frequently Asked Questions\n\n### Where is the protocol specification?\n\nIf you are looking for some prose explaining how all this works, **this is it**. **Hawk** is being developed as an open source\nproject instead of a standard. In other words, the [code](/hueniverse/hawk/tree/master/lib) is the specification. Not sure about\nsomething? Open an issue!\n\n### Is it done?\n\nAt if version 0.10.0, **Hawk** is feature-complete. However, until this module reaches version 1.0.0 it is considered experimental\nand is likely to change. This also means your feedback and contribution are very welcome. Feel free to open issues with questions\nand suggestions.\n\n### Where can I find **Hawk** implementations in other languages?\n\n**Hawk**'s only reference implementation is provided in JavaScript as a node.js module. However, others are actively porting it to other\nplatforms. There is already a [PHP](https://github.com/alexbilbie/PHP-Hawk),\n[.NET](https://github.com/pcibraro/hawknet), and [JAVA](https://github.com/wealdtech/hawk) libraries available. The full list\nis maintained [here](https://github.com/hueniverse/hawk/issues?labels=port). Please add an issue if you are working on another\nport. A cross-platform test-suite is in the works.\n\n### Why isn't the algorithm part of the challenge or dynamically negotiated?\n\nThe algorithm used is closely related to the key issued as different algorithms require different key sizes (and other\nrequirements). While some keys can be used for multiple algorithm, the protocol is designed to closely bind the key and algorithm\ntogether as part of the issued credentials.\n\n### Why is Host and Content-Type the only headers covered by the request MAC?\n\nIt is really hard to include other headers. Headers can be changed by proxies and other intermediaries and there is no\nwell-established way to normalize them. Many platforms change the case of header field names and values. The only\nstraight-forward solution is to include the headers in some blob (say, base64 encoded JSON) and include that with the request,\nan approach taken by JWT and other such formats. However, that design violates the HTTP header boundaries, repeats information,\nand introduces other security issues because firewalls will not be aware of these \"hidden\" headers. In addition, any information\nrepeated must be compared to the duplicated information in the header and therefore only moves the problem elsewhere.\n\n### Why not just use HTTP Digest?\n\nDigest requires pre-negotiation to establish a nonce. This means you can't just make a request - you must first send\na protocol handshake to the server. This pattern has become unacceptable for most web services, especially mobile\nwhere extra round-trip are costly.\n\n### Why bother with all this nonce and timestamp business?\n\n**Hawk** is an attempt to find a reasonable, practical compromise between security and usability. OAuth 1.0 got timestamp\nand nonces halfway right but failed when it came to scalability and consistent developer experience. **Hawk** addresses\nit by requiring the client to sync its clock, but provides it with tools to accomplish it.\n\nIn general, replay protection is a matter of application-specific threat model. It is less of an issue on a TLS-protected\nsystem where the clients are implemented using best practices and are under the control of the server. Instead of dropping\nreplay protection, **Hawk** offers a required time window and an optional nonce verification. Together, it provides developers\nwith the ability to decide how to enforce their security policy without impacting the client's implementation.\n\n### What are `app` and `dlg` in the authorization header and normalized mac string?\n\nThe original motivation for **Hawk** was to replace the OAuth 1.0 use cases. This included both a simple client-server mode which\nthis module is specifically designed for, and a delegated access mode which is being developed separately in\n[Oz](https://github.com/hueniverse/oz). In addition to the **Hawk** use cases, Oz requires another attribute: the application id `app`.\nThis provides binding between the credentials and the application in a way that prevents an attacker from tricking an application\nto use credentials issued to someone else. It also has an optional 'delegated-by' attribute `dlg` which is the application id of the\napplication the credentials were directly issued to. The goal of these two additions is to allow Oz to utilize **Hawk** directly,\nbut with the additional security of delegated credentials.\n\n### What is the purpose of the static strings used in each normalized MAC input?\n\nWhen calculating a hash or MAC, a static prefix (tag) is added. The prefix is used to prevent MAC values from being\nused or reused for a purpose other than what they were created for (i.e. prevents switching MAC values between a request,\nresponse, and a bewit use cases). It also protects against expliots created after a potential change in how the protocol\ncreates the normalized string. For example, if a future version would switch the order of nonce and timestamp, it\ncan create an exploit opportunity for cases where the nonce is similar in format to a timestamp.\n\n### Does **Hawk** have anything to do with OAuth?\n\nShort answer: no.\n\n**Hawk** was originally proposed as the OAuth MAC Token specification. However, the OAuth working group in its consistent\nincompetence failed to produce a final, usable solution to address one of the most popular use cases of OAuth 1.0 - using it\nto authenticate simple client-server transactions (i.e. two-legged). As you can guess, the OAuth working group is still hard\nat work to produce more garbage.\n\n**Hawk** provides a simple HTTP authentication scheme for making client-server requests. It does not address the OAuth use case\nof delegating access to a third party. If you are looking for an OAuth alternative, check out [Oz](https://github.com/hueniverse/oz).\n\n\n# Acknowledgements\n\n**Hawk** is a derivative work of the [HTTP MAC Authentication Scheme](http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-05) proposal\nco-authored by Ben Adida, Adam Barth, and Eran Hammer, which in turn was based on the OAuth 1.0 community specification.\n\nSpecial thanks to Ben Laurie for his always insightful feedback and advice.\n\nThe **Hawk** logo was created by [Chris Carrasco](http://chriscarrasco.com).\n",
-  "readmeFilename": "README.md",
-  "bugs": {
-    "url": "https://github.com/hueniverse/hawk/issues"
-  },
-  "homepage": "https://github.com/hueniverse/hawk",
-  "_id": "hawk@1.0.0",
-  "_from": "hawk@~1.0.0"
-}

data/lib/node_modules/npm/node_modules/request/node_modules/http-signature/LICENSE

@@ -1,18 +0,0 @@
-Copyright Joyent, Inc. All rights reserved.
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to
-deal in the Software without restriction, including without limitation the
-rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
-sell copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
-IN THE SOFTWARE.

data/lib/node_modules/npm/node_modules/request/node_modules/http-signature/README.md

@@ -1,75 +0,0 @@
-# node-http-signature
-
-node-http-signature is a node.js library that has client and server components
-for Joyent's [HTTP Signature Scheme](http_signing.md).
-
-## Usage
-
-Note the example below signs a request with the same key/cert used to start an
-HTTP server. This is almost certainly not what you actaully want, but is just
-used to illustrate the API calls; you will need to provide your own key
-management in addition to this library.
-
-### Client
-
-    var fs = require('fs');
-    var https = require('https');
-    var httpSignature = require('http-signature');
-
-    var key = fs.readFileSync('./key.pem', 'ascii');
-
-    var options = {
-      host: 'localhost',
-      port: 8443,
-      path: '/',
-      method: 'GET',
-      headers: {}
-    };
-
-    // Adds a 'Date' header in, signs it, and adds the
-    // 'Authorization' header in.
-    var req = https.request(options, function(res) {
-      console.log(res.statusCode);
-    });
-
-
-    httpSignature.sign(req, {
-      key: key,
-      keyId: './cert.pem'
-    });
-
-    req.end();
-
-### Server
-
-    var fs = require('fs');
-    var https = require('https');
-    var httpSignature = require('http-signature');
-
-    var options = {
-      key: fs.readFileSync('./key.pem'),
-      cert: fs.readFileSync('./cert.pem')
-    };
-
-    https.createServer(options, function (req, res) {
-      var rc = 200;
-      var parsed = httpSignature.parseRequest(req);
-      var pub = fs.readFileSync(parsed.keyId, 'ascii');
-      if (!httpSignature.verifySignature(parsed, pub))
-        rc = 401;
-
-      res.writeHead(rc);
-      res.end();
-    }).listen(8443);
-
-## Installation
-
-    npm install http-signature
-
-## License
-
-MIT.
-
-## Bugs
-
-See <https://github.com/joyent/node-http-signature/issues>.

data/lib/node_modules/npm/node_modules/request/node_modules/http-signature/http_signing.md

@@ -1,296 +0,0 @@
-# Abstract
-
-This document describes a way to add origin authentication, message integrity,
-and replay resistance to HTTP REST requests.  It is intended to be used over
-the HTTPS protocol.
-
-# Copyright Notice
-
-Copyright (c) 2011 Joyent, Inc. and the persons identified as document authors.
-All rights reserved.
-
-Code Components extracted from this document must include MIT License text.
-
-# Introduction
-
-This protocol is intended to provide a standard way for clients to sign HTTP
-requests.  RFC2617 (HTTP Authentication) defines Basic and Digest authentication
-mechanisms, and RFC5246 (TLS 1.2) defines client-auth, both of which are widely
-employed on the Internet today.  However, it is common place that the burdens of
-PKI prevent web service operators from deploying that methodoloy, and so many
-fall back to Basic authentication, which has poor security characteristics.
-
-Additionally, OAuth provides a fully-specified alternative for authorization
-of web service requests, but is not (always) ideal for machine to machine
-communication, as the key acquisition steps (generally) imply a fixed
-infrastructure that may not make sense to a service provider (e.g., symmetric
-keys).
-
-Several web service providers have invented their own schemes for signing
-HTTP requests, but to date, none have been placed in the public domain as a
-standard.  This document serves that purpose.  There are no techniques in this
-proposal that are novel beyond previous art, however, this aims to be a simple
-mechanism for signing these requests.
-
-# Signature Authentication Scheme
-
-The "signature" authentication scheme is based on the model that the client must
-authenticate itself with a digital signature produced by either a private
-asymmetric key (e.g., RSA) or a shared symmetric key (e.g., HMAC).  The scheme
-is parameterized enough such that it is not bound to any particular key type or
-signing algorithm.  However, it does explicitly assume that clients can send an
-HTTP `Date` header.
-
-## Authorization Header
-
-The client is expected to send an Authorization header (as defined in RFC 2617)
-with the following parameterization:
-
-    credentials := "Signature" params
-    params := 1#(keyId | algorithm | [headers] | [ext] | signature)
-    digitalSignature := plain-string
-
-    keyId := "keyId" "=" <"> plain-string <">
-    algorithm := "algorithm" "=" <"> plain-string <">
-    headers := "headers" "=" <"> 1#headers-value <">
-    ext := "ext" "=" <"> plain-string <">
-    signature := "signature" "=" <"> plain-string <">
-
-    headers-value := plain-string
-    plain-string   = 1*( %x20-21 / %x23-5B / %x5D-7E )
-
-### Signature Parameters
-
-#### keyId
-
-REQUIRED.  The `keyId` field is an opaque string that the server can use to look
-up the component they need to validate the signature.  It could be an SSH key
-fingerprint, an LDAP DN, etc.  Management of keys and assignment of `keyId` is
-out of scope for this document.
-
-#### algorithm
-
-REQUIRED. The `algorithm` parameter is used if the client and server agree on a
-non-standard digital signature algorithm.  The full list of supported signature
-mechanisms is listed below.
-
-#### headers
-
-OPTIONAL.  The `headers` parameter is used to specify the list of HTTP headers
-used to sign the request.  If specified, it should be a quoted list of HTTP
-header names, separated by a single space character.  By default, only one
-HTTP header is signed, which is the `Date` header.  Note that the list MUST be
-specified in the order the values are concatenated together during signing. To
-include the HTTP request line in the signature calculation, use the special
-`request-line` value.  While this is overloading the definition of `headers` in
-HTTP linguism, the request-line is defined in RFC 2616, and as the outlier from
-headers in useful signature calculation, it is deemed simpler to simply use
-`request-line` than to add a separate parameter for it.
-
-#### extensions
-
-OPTIONAL.  The `extensions` parameter is used to include additional information
-which is covered by the request.  The content and format of the string is out of
-scope for this document, and expected to be specified by implementors.
-
-#### signature
-
-REQUIRED.  The `signature` parameter is a `Base64` encoded digital signature
-generated by the client. The client uses the `algorithm` and `headers` request
-parameters to form a canonicalized `signing string`.  This `signing string` is
-then signed with the key associated with `keyId` and the algorithm
-corresponding to `algorithm`.  The `signature` parameter is then set to the
-`Base64` encoding of the signature.
-
-### Signing String Composition
-
-In order to generate the string that is signed with a key, the client MUST take
-the values of each HTTP header specified by `headers` in the order they appear.
-
-1. If the header name is not `request-line` then append the lowercased header
-   name followed with an ASCII colon `:` and an ASCII space ` `.
-2. If the header name is `request-line` then appened the HTTP request line,
-   otherwise append the header value.
-3. If value is not the last value then append an ASCII newline `\n`. The string
-   MUST NOT include a trailing ASCII newline.
-
-# Example Requests
-
-All requests refer to the following request (body ommitted):
-
-    POST /foo HTTP/1.1
-    Host: example.org
-    Date: Tue, 07 Jun 2011 20:51:35 GMT
-    Content-Type: application/json
-    Content-MD5: h0auK8hnYJKmHTLhKtMTkQ==
-    Content-Length: 123
-
-The "rsa-key-1" keyId refers to a private key known to the client and a public
-key known to the server. The "hmac-key-1" keyId refers to key known to the
-client and server.
-
-## Default parameterization
-
-The authorization header and signature would be generated as:
-
-    Authorization: Signature keyId="rsa-key-1",algorithm="rsa-sha256",signature="Base64(RSA-SHA256(signing string))"
-
-The client would compose the signing string as:
-
-    date: Tue, 07 Jun 2011 20:51:35 GMT
-
-## Header List
-
-The authorization header and signature would be generated as:
-
-    Authorization: Signature keyId="rsa-key-1",algorithm="rsa-sha256",headers="request-line date content-type content-md5",signature="Base64(RSA-SHA256(signing string))"
-
-The client would compose the signing string as (`+ "\n"` inserted for
-readability):
-
-    POST /foo HTTP/1.1 + "\n"
-    date: Tue, 07 Jun 2011 20:51:35 GMT + "\n"
-    content-type: application/json + "\n"
-    content-md5: h0auK8hnYJKmHTLhKtMTkQ==
-
-## Algorithm
-
-The authorization header and signature would be generated as:
-
-    Authorization: Signature keyId="hmac-key-1",algorithm="hmac-sha1",signature="Base64(HMAC-SHA1(signing string))"
-
-The client would compose the signing string as:
-
-    date: Tue, 07 Jun 2011 20:51:35 GMT
-
-# Signing Algorithms
-
-Currently supported algorithm names are:
-
-* rsa-sha1
-* rsa-sha256
-* rsa-sha512
-* dsa-sha1
-* hmac-sha1
-* hmac-sha256
-* hmac-sha512
-
-# Security Considerations
-
-## Default Parameters
-
-Note the default parameterization of the `Signature` scheme is only safe if all
-requests are carried over a secure transport (i.e., TLS).  Sending the default
-scheme over a non-secure transport will leave the request vulnerable to
-spoofing, tampering, replay/repudiaton, and integrity violations (if using the
-STRIDE threat-modeling methodology).
-
-## Insecure Transports
-
-If sending the request over plain HTTP, service providers SHOULD require clients
-to sign ALL HTTP headers, and the `request-line`.  Additionally, service
-providers SHOULD require `Content-MD5` calculations to be performed to ensure
-against any tampering from clients.
-
-## Nonces
-
-Nonces are out of scope for this document simply because many service providers
-fail to implement them correctly, or do not adopt security specfiications
-because of the infrastructure complexity.  Given the `header` parameterization,
-a service provider is fully enabled to add nonce semantics into this scheme by
-using something like an `x-request-nonce` header, and ensuring it is signed
-with the `Date` header.
-
-## Clock Skew
-
-As the default scheme is to sign the `Date` header, service providers SHOULD
-protect against logged replay attacks by enforcing a clock skew.  The server
-SHOULD be synchronized with NTP, and the recommendation in this specification
-is to allow 300s of clock skew (in either direction).
-
-## Required Headers to Sign
-
-It is out of scope for this document to dictate what headers a service provider
-will want to enforce, but service providers SHOULD at minimum include the
-`Date` header.
-
-# References
-
-## Normative References
-
-* [RFC2616] Hypertext Transfer Protocol -- HTTP/1.1
-* [RFC2617] HTTP Authentication: Basic and Digest Access Authentication
-* [RFC5246] The Transport Layer Security (TLS) Protocol Version 1.2
-
-## Informative References
-
-    Name: Mark Cavage (editor)
-    Company: Joyent, Inc.
-    Email: mark.cavage@joyent.com
-    URI: http://www.joyent.com
-
-# Appendix A - Test Values
-
-The following test data uses the RSA (2048b) keys, which we will refer
-to as `keyId=Test` in the following samples:
-
-   -----BEGIN PUBLIC KEY-----
-   MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCFENGw33yGihy92pDjZQhl0C3
-   6rPJj+CvfSC8+q28hxA161QFNUd13wuCTUcq0Qd2qsBe/2hFyc2DCJJg0h1L78+6
-   Z4UMR7EOcpfdUE9Hf3m/hs+FUR45uBJeDK1HSFHD8bHKD6kv8FPGfJTotc+2xjJw
-   oYi+1hqp1fIekaxsyQIDAQAB
-   -----END PUBLIC KEY-----
-
-    -----BEGIN RSA PRIVATE KEY-----
-    MIICXgIBAAKBgQDCFENGw33yGihy92pDjZQhl0C36rPJj+CvfSC8+q28hxA161QF
-    NUd13wuCTUcq0Qd2qsBe/2hFyc2DCJJg0h1L78+6Z4UMR7EOcpfdUE9Hf3m/hs+F
-    UR45uBJeDK1HSFHD8bHKD6kv8FPGfJTotc+2xjJwoYi+1hqp1fIekaxsyQIDAQAB
-    AoGBAJR8ZkCUvx5kzv+utdl7T5MnordT1TvoXXJGXK7ZZ+UuvMNUCdN2QPc4sBiA
-    QWvLw1cSKt5DsKZ8UETpYPy8pPYnnDEz2dDYiaew9+xEpubyeW2oH4Zx71wqBtOK
-    kqwrXa/pzdpiucRRjk6vE6YY7EBBs/g7uanVpGibOVAEsqH1AkEA7DkjVH28WDUg
-    f1nqvfn2Kj6CT7nIcE3jGJsZZ7zlZmBmHFDONMLUrXR/Zm3pR5m0tCmBqa5RK95u
-    412jt1dPIwJBANJT3v8pnkth48bQo/fKel6uEYyboRtA5/uHuHkZ6FQF7OUkGogc
-    mSJluOdc5t6hI1VsLn0QZEjQZMEOWr+wKSMCQQCC4kXJEsHAve77oP6HtG/IiEn7
-    kpyUXRNvFsDE0czpJJBvL/aRFUJxuRK91jhjC68sA7NsKMGg5OXb5I5Jj36xAkEA
-    gIT7aFOYBFwGgQAQkWNKLvySgKbAZRTeLBacpHMuQdl1DfdntvAyqpAZ0lY0RKmW
-    G6aFKaqQfOXKCyWoUiVknQJAXrlgySFci/2ueKlIE1QqIiLSZ8V8OlpFLRnb1pzI
-    7U1yQXnTAEFYM560yJlzUpOb1V4cScGd365tiSMvxLOvTA==
-    -----END RSA PRIVATE KEY-----
-
-And all examples use this request:
-
-    POST /foo?param=value&pet=dog HTTP/1.1
-    Host: example.com
-    Date: Thu, 05 Jan 2012 21:31:40 GMT
-    Content-Type: application/json
-    Content-MD5: Sd/dVLAcvNLSq16eXua5uQ==
-    Content-Length: 18
-
-    {"hello": "world"}
-
-### Default
-
-The string to sign would be:
-
-    date: Thu, 05 Jan 2012 21:31:40 GMT
-
-The Authorization header would be:
-
-    Authorization: Signature keyId="Test",algorithm="rsa-sha256",signature="JldXnt8W9t643M2Sce10gqCh/+E7QIYLiI+bSjnFBGCti7s+mPPvOjVb72sbd1FjeOUwPTDpKbrQQORrm+xBYfAwCxF3LBSSzORvyJ5nRFCFxfJ3nlQD6Kdxhw8wrVZX5nSem4A/W3C8qH5uhFTRwF4ruRjh+ENHWuovPgO/HGQ="
-
-### All Headers
-
-Parameterized to include all headers, the string to sign would be (`+ "\n"`
-inserted for readability):
-
-    POST /foo?param=value&pet=dog HTTP/1.1 + "\n"
-    host: example.com + "\n"
-    date: Thu, 05 Jan 2012 21:31:40 GMT + "\n"
-    content-type: application/json + "\n"
-    content-md5: Sd/dVLAcvNLSq16eXua5uQ== + "\n"
-    content-length: 18
-
-The Authorization header would be:
-
-    Authorization: Signature keyId="Test",algorithm="rsa-sha256",headers="request-line host date content-type content-md5 content-length",signature="Gm7W/r+e90REDpWytALMrft4MqZxCmslOTOvwJX17ViEBA5E65QqvWI0vIH3l/vSsGiaMVmuUgzYsJLYMLcm5dGrv1+a+0fCoUdVKPZWHyImQEqpLkopVwqEH67LVECFBqFTAKlQgBn676zrfXQbb+b/VebAsNUtvQMe6cTjnDY="
-