wkovacs64 / hibp Goto Github PK

Following on from #24, what if the resolved value from pwnedPasswordRange was a simple object mapping the suffixes to the count (interface PwnedPasswordSuffix { [suffix: string]: number; })? E.g. the current test:

becomes:

      return expect(pwnedPasswordRange('5BAA6')).resolves.toEqual({
        '003D68EB55068C33ACE09247EE4C639306B': 3,
        '1E4C9B93F3F0682250B6CF8331B7EE68FD8': 3303003,
        '01330C689E5D64F660D6947A93AD634EF8F': 1,
      });

This would substantially simplify the most common usage, as expressed by the implementation of pwnedPassword, from:

to:

  return (
    pwnedPasswordRange(prefix, options)
      .then((arr) => (arr[suffix] || 0))
  );

which is also slightly more efficient than an O(n) scan of the result array.

I'm happy to PR an implementation if this is a direction people are happy with.

The mere presence of the default export appears to break webpack tree-shaking. Also, it has been suggested by Dr. Axel Rauschmayer that exporting an object as the "default"-named export is probably an anti-pattern when all you want to do is provide access to its properties.

See the 2016/04/26 update in Tim Oxley's ES Modules post.

Need to add support for the newly released API functionality of searching pwned passwords by range.

haveibeenpwned.com recently (mid-January, 2019) adjusted their API abuse prevention policies and now many API consumers are being blocked. The primary target appears to be the User-Agent string in the API request, but there is more to the story as multiple users with the same UA can receive different results for the same request (e.g. one blocked, one succeeds). IP address and/or region may also be playing a part. It also seems the rules are most strict surrounding the breachedaccount endpoint.

The requirements in the haveibeenpwned API documentation state that a User-Agent must be included in all API requests to avoid being blocked. hibp does this this outside of the browser (i.e. Node.js), but it is not currently possible for hibp to set its own User-Agent when running in the browser because haveibeenpwned.com does not include it in the Access-Control-Allow-Headers header field of a preflight response. (Try it out on test-cors.org and you will see it fail. See MDN's CORS page for more details.) Furthermore, some browsers (e.g. Chrome) will even block requests client-side that attempt to modify the UA as they consider it unsafe, so the problem would still exist for some users even if the CORS rules were adjusted to allow it.

Currently, it seems like most/all browser UA strings are being blocked outright. The test link in the API documentation fails on every browser I've tested from various devices, locations, and networks. I don't know if this is intentional and browser support needs to be dropped from hibp or if the abuse prevention rules are too strict and need adjusted. Edit (2019-01-25): Confirmed with Troy that this is intentional.

In versions of hibp prior to 7.4.0, the error would appear as such:

Error: Forbidden - no user agent has been specified in the request.

This is because the haveibeenpwned.com API documentation states a 403 Forbidden response would occur in the case of a missing User-Agent header field in the request. However, this is not the only case where they respond with 403 Forbidden now, so that error message is no longer accurate.

hibp version 7.4.0 includes a more specific error message, indicating if you are being blocked by haveibeenpwned.com when a Cloudflare Ray ID is present in the response header:

Error: Request blocked, contact haveibeenpwned.com if this continues (Ray ID: xxxxxxxx-xyz)

If no Cloudflare Ray ID is present, you will get a more generalized error:

Error: Forbidden - access denied.

Related issues:

#38
wKovacs64/pwned#27
wKovacs64/pwned#30

https://www.troyhunt.com/authentication-and-the-have-i-been-pwned-api/

https://haveibeenpwned.com/API/v3#Authorisation

https://haveibeenpwned.com/API/v3#RateLimiting

https://haveibeenpwned.com/API/v3#BreachesForAccount

Continuing the discussion from #23 (comment) , should pwnedPasswordRange resolve to more easily consumable JS instead of the raw text of the response? Is there any use case where a consumer would want/need to access the plain text? 🤔

CC @danieladams456

Depending on my availability over the next bit, I would be interested in trying to implement this feature.

Currently the pwnedPassword check uses the v1 api, but it would be nice to use the more secure v2 hash range api. This module could depend upon pwnedPasswordRange.js and provide the higher level API without needing to search through the results.

I was envisioning using this as a type of password strength tester for user signup beyond the basic length/character set, so there could be a case where you were ok with 5 pwns but not 5,000. I would add a maxPwns: number parameter to the options object (convenient it's already there!) to facilitate that behavior. Default maxPwns would be 1, and the method would return a boolean as it does currently.

The API documentation (API.md) and types should update as the changes are implemented, but we may also need to update:

• The README
• The GitHub Pages site (/docs)
• The RunKit example (/example)
• The Migration guide

Looks like all API methods fail when trying to call them from a web worker or extension background threads since window is undefined.

Looking at src/api/web-fetch.ts it looks like it assumes it is running in a NodeJS environment if window is undefined.

Perhaps a more accurate check to see if native fetch is available can be simply 'fetch' in globalThis

There's really no need for this to be included in the project. We will still generate the appropriate source maps during the build process and any future debugging can install/register source-map-support prior to reproducing the error.

In addition to the good feeling 😸 of removing a project dependency, it also reduces the size of the Node-targeting builds (CommonJS in lib and ES modules in es) substantially when included via a bundler. This is arguably a prerequisite to removing the browser field in package.json, another imminent goal.

Not sure if this in an appropriate place to report this issue, but, I am coming back to a Vue2 + Vuetify project, which I haven't touched in about six months.

On running npm run serve, I am met with this message;

ERROR  Failed to compile with 1 error

error  in ./node_modules/hibp/dist/esm/api/haveibeenpwned/fetchFromApi.mjs

Module parse failed: Unexpected token (18:19)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
|    * should never happen.
|    */
>   retryAfterSeconds;
| 
|   constructor(retryAfter, message, options) {
...

The only method that I am importing from your library is

import { pwnedPassword } from 'hibp';

and if I remove this import, I no longer receive the error

Again, I am not sure exactly where, or why, this error is occurring, but as I say I have changed nothing in my project for the past 6 months

EDIT: This occurs when using hibp v11.1.0, using v11.0.0 I do not get any errors and all works fine

Since v14.1.0 we have started seeing an error occurring at

Debugging through I can see that process is actually defined when this code executes. I think perhaps this could be a Next.js thing but I am not totally sure. We call hibp from the browser I should add.

I wonder if using typeof window === 'undefined' rather than typeof process !== 'undefined' might be an approach which would have the same effect but not impact on Next.js users.

Thanks.

Including this file https://unpkg.com/[email protected]/dist/hibp.js in my HTML page gives me this error:

Uncaught ReferenceError: exports is not defined
    at Object.eval (hibp.js:237)
    at eval (hibp.js:238)
    at Object.<anonymous> (hibp.js:133)
    at __webpack_require__ (hibp.js:30)
    at eval (hibp.js:1)
    at Object.<anonymous> (hibp.js:283)
    at __webpack_require__ (hibp.js:30)
    at hibp.js:76
    at hibp.js:79
    at webpackUniversalModuleDefinition (hibp.js:9)

Which is happening in this line

/* harmony default export */ __webpack_exports__["default"] = (hibp);
module.exports = exports['default'];
/* WEBPACK VAR INJECTION */}.call(__webpack_exports__, __webpack_require__(28)(module)))

With version 4.1.0 it's working fine

Currently, importing hibp in a project built with webpack will use the UMD build when targeting the web (the default behavior when webpack's target field is unspecified). This is suboptimal for various reasons and it should probably be removed for now (following redux's lead here).

It appears the unpkg CDN checks the unpkg field first when resolving the entry point if unspecified, so we should replace browser with that. Otherwise, users will have to include the dist/hibp.min.js file path in their <script> tags.

https://haveibeenpwned.com/API/v3#BreachesForAccount

Symptom:

hibp requests made outside of a browser (e.g. Node.js) result in the following:

Error: Forbidden - no user agent has been specified in the request.

Synopsis:

As first noticed on 2018-06-26, the remote API seems to have started enforcing a long documented but never enforced rule requiring a User-Agent header be included in all API requests. hibp does not currently include this header (see below for reasons why).

Backstory:

I (original author of this library) had every intention of honoring this requirement, but ran into what I believe is a misconfiguration or partial implementation of CORS on the API side of things which prevented consumers from sending a custom User-Agent request header in the browser. I contacted the API author/maintainer and provided a very detailed analysis of my findings, but the CORS configuration for the API remained the same. As such, hibp does not currently send a User-Agent header in its requests, as I noticed the rule was not being enforced anyway.

Proposed Solution:

hibp can check if it's running outside the browser and include a custom User-Agent header in its requests. In a browser environment, it will continue to allow the browser to include its own User-Agent and thus avoid CORS.

I couldn't find anything in sources so I assume there's no timeout on doing fetch on HIBP API?
It would be nice to have an option to define it in config, as well as some default timeout.

https://allcontributors.org

Consider adding Hudson Rock's complimentary data to receive additional intelligence about an email address, or domain that was compromised in global Infostealer attacks.

Email sample: https://cavalier.hudsonrock.com/api/json/v2/osint-tools/[email protected]
Domain sample: https://cavalier.hudsonrock.com/api/json/v2/osint-tools/search-by-domain?domain=tesla.com

Free API key and full documentation is available here: https://cavalier.hudsonrock.com/docs

Thank you.

There is an error with this repository's Renovate configuration that needs to be fixed. As a precaution, Renovate will stop PRs until it is resolved.

Error type: undefined. Note: this is a nested preset so please contact the preset author if you are unable to fix it yourself.

I'm trying to use hibp in a React Native project, but I'm getting this error when importing the module and starting the app in dev mode:

In this environment the sources for assign MUST be an object. This error is a performance optimization and not spec compliant.

    Object.assign @ Object.es6.js:37:14
    <unknown> @ hibp.js:23:14
    loadModuleImplementation @ require.js:292:4
    guardedLoadModule @ require.js:186:11
    metroRequire @ require.js:115:72
    […]

As far as I can see, this is caused by this RN polyfill, triggered by this line in hibp, which passes false as the second parameter to Object.assign because navigator is an object in this scenario (the navigator global of the browser attached for debugging).

Like the error message says, hibp isn't doing anything wrong here; but I guess this would be fairly simple to prevent, by modifying the Object.assign call to always pass an object?

"browsers": [
  "> 1%",
  "last 2 versions"
],

This will be required if #8 is implemented, as the current CommonJS/ES module builds contain features that don't work across all the browsers this project aims to support (template literals, in particular).

It should really be added regardless, as people may even be wanting to circumvent the browser field already and explicitly import a non-UMD build on their own. Currently, when attempting to bundle a non-UMD build with webpack, the included UglifyJsPlugin will error during minification as it can't handle ES2015 features yet. (There are workarounds for this, such as bringing in the next version of UglifyJs or using a different minifier all together.)

Can you explain what the LogoType field in the breach data is (or could be) used for? I know what SVG and JPG are, but to what data do they refer? I don't see any reference to it in the source code.

Hello

I am trying to check really simple passwords - and no matches found. May be I am doing something wrong?

const hibp = require('hibp');
const sha1 = require('sha1');
const shad = sha1('123456'); // the most simple password

const firstFive = shad.substr(0, 5);
const rest = shad.substr(5);
hibp
    .pwnedPasswordRange(firstFive)
    .then(data => {

        data.forEach(i => {

            if (i.suffix === rest) {
                console.log('FOUND');
            }
        });

    });

Is there a way to get the value of retry-after when rate limiting response is received?

Hello. Thank you for the project.
Am use for React, but have problem with CORS
How to fix it?
https://skr.sh/i/170221/DZ713XeI.jpg

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Datasource	Name	Replacement PR?
npm	@babel/plugin-proposal-class-properties
npm	@babel/plugin-proposal-object-rest-spread

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository