guyht / notp Goto Github PK

It's rather a curious question. I have noted, mostly TOTP JS libraries are not being maintained for years. What's stopping devs to maintain these libraries.

const result = notp.totp.verify(token, key)

Here result is a object any way,But token is valid would return { delta: 0 }

For my use case (TOTP codes valid for 24 hours that I need to know the day before) I need to generate TOTP codes in the future, not only in the present, but totp.gen() explicitly forbids this possibility.

Is there a reason for this limitation? Would it be possible to allow changing _t just like it is possible to change time?

totp.verify docs are wrong, says the default window is 6 but it relies on hotp.verify which has a default window of 50.

I'd like to be able to casually run my own tests and examples without explicitly setting NODE_ENV.

I don't see a security benefit to this.

If the user of this library is somehow exposing the options object to a client they can already arbitrary adjust the window size to something like 100,000 which is just as insecure, so there's no security benefit.

In fact, I just tested with a window of 100,000 and an arbitrary token 957 124 and in in 5 out of 10 trials each taking about 2 seconds I was able to verify.

Lots of sites generate a random binary string as the key, and base32 encode it.

Your code:
var hmac = crypto.createHmac('SHA1', new Buffer(key));

takes the binary key, but treats it as utf8 encoded.

new Buffer(key, 'binary') would be better, but http://nodejs.org/api/buffer.html says that the 'binary' encoding " is deprecated and should be avoided in favor of Buffer objects where possible. This encoding will be removed in future versions of Node.".

So what really needs to happen is for the base32 decode function to decode the string into a buffer rather than a string.

As a test case, try the base32-encoded secret 'ZZZZZZZZZZZZZZZZ' on notp and on google authenticator, and see that they get different results.

Hey, I have obtained a TOTP shared secret key from GitHub and I have manually inserted the secret to both Google Authenticator and NOTP and verified that the values are correct. I did this twice manually and once using the QR code from GitHub to set up Google Authenticator.

Here's my NOTP code, I am using literally just this line:

console.log(notp.totp.gen('<the secret>'));

The secret is a string in the format of 16 lowercase letters and numbers as provided by GitHub.

Google Authenticator and NOTP give me totally different code. I have tried to cross the time window boundary to check if maybe NOTP was giving me a token one window too old or too new, but they just seems to be completely unrelated. Needless to say GitHub won't accept my TOTP token, but will Google Authenticator's.

Do I miss options which I should be using? According to the READM, the only relevant option is time which I think the defaults cover and match what Google Authenticator is doing, so I am confused as to why the difference exists.

Steps to Reproduce:

• Go through the GitHub flow's for reconfiguring 2FA
• On the QR code page, do not use the QA code but click for text code and copy that
• Insert the secret manually into Google Authenticator and triple check it
• Insert it also into the code above and quadruple check it
• Confirm they do not match

The latest update from OATH includes a new challenge-response schema as part of the OTP tools.
Specifications can be found http://tools.ietf.org/html/rfc6287 (http://www.openauthentication.org/specifications) .
It should be included to support all the OATH Authentication Methods in the module.

See:
https://runkit.com/embed/97u6bi5kd9bg

var notp = require("notp")

console.log(notp.hotp.verify("AAAAAAAAAAAAAAAAAA", "812658", {counter: 1}));

Always returns null.

The documentation shows var login = notp.totp.verify(token, key); under Usage, but it throws trying to get opt.time if you actually do that. I'd be happy to PR if someone weighs in on whether fixing the docs or opt ||= {} would be preferred.

Node's crypto module began development before node's architecture was finalized.

What is now written as

crypto.createHmac('sha1').update(bytes).digest('hex');

will someday be written more like

var cryptoStream = crypto.create('hmac', 'sha1');
byteStream.pipe(cryptoStream);
cryptoStream.on('end', function (digest) {
  console.log(digest.toString('hex'))
});

Otherwise, the update function becomes blocking.

Although node will probably always be backwards compatible, I was porting this to the browser - which is just a few lines of changes thanks to your clean and excellent code - and the WebCrypto API is already asynchronous (Promise, not callback) so the port is not 1:1.

Hi, I love this library because it is super minimal and gets the job done. The only problem is it doesn't have any type definitions for Typescript. Was wondering if there were any plans on creating type definitions otherwise I will just create one on DefinetlyTyped @types repo.

:)

I am using the notp.totp.verify method to verify a token for a base32 secret, but it fails for every token. The token is generated on the authenticator app, I tested with both Google's and Microsoft's.

I used the secret to generate totp with notp.totp.gen, but it generates different token than the ones generated by the google's and microsoft's authenticator app.

I'm guessing that's why the verification fails as well, since for a given time step the token doesn't match.

i'm using default time step of 30 seconds.

Integrate Travis CI for automated testing.

intToBytes(9999999999999) will give [0, 0, 0, 0, 78, 114, 159, 255] which is <Buffer 00 00 00 00 4e 72 9f ff>

But 9999999999999 decimal to hexadecimal must return 00 00 09 18 4E 72 9F FF

Codes from here:

var base32 = require('thirty-two');

var key = 'secret key for the user';

// encoded will be the secret key, base32 encoded
var encoded = base32.encode(key);

I mean, notp is a Node.js module, isn't it? I would rather use

buf.toString('base64')

without additional dependenci(es).

Relevant documentation:

• https://nodejs.org/api/buffer.html#buffer_buffers_and_character_encodings

As the Readme says, The allowable margin for the counter. The function will check window codes in the future against the provided token. i.e. if window = 100 and counter = 5 all tokens between 5 and 105 will be checked against the supplied token Default - 50 for HOTP code verification.
As I can see, the library now implies another logic (issue #21 says the same).
I have made a PR#39. Please, take a look if you'll have a chance.

For now I can't pass 0 as window size because of that check: var window = opt.window || 50;
I assume that comparing with umdefined should be performed in spite of the notp library is kind of low-level one.
See the PR #41.

I created a browser-friendly fork:

https://github.com/daplie/botp

The main changes are that I had to make a few calls asynchronous (as per previous issue) and shim out a single sha1-hmac function.

For browsers that support WebCrypto, there are no dependencies.

For old IE (pre-Edge) and old Android (pre 4.x) there's a fair bit of the forge library that needs to be included.

If you're interested in working jointly on an notp version 3 that supports these changes let me know. I tried to keep my changes as minimal as possible.

I also built fully-functional Authenticator apps on top of botp and notp:

• Browser Authenticator
• Node Authenticator

The example application has not been updated for the new API and so does not work.

This is a security issue. Once used, OTP should not be verified as success.
But right now it goes this way:
for(var i = counter - window; i <= counter + window; ++i)

should be:
for(var i = counter; i <= counter + window; ++i)

import notp from 'notp' seem to be returning undefined, but
const notp = requires('notp') seem to return {hotp, totp} properly.

it's pretty weird but this does exist.

Node: 12.16.3
notp: ^2.0.3

I might be misunderstanding something but I think there's at least one error in the HTOP.verify doc:

window - The allowable margin for the counter. The function will check

•     'W' codes in the future against the provided passcode.  Note,
  

•     it is the calling applications responsibility to keep track of
  

•     'W' and increment it for each password check, and also to adjust
  

•     it accordingly in the case where the client and server become
  

•     out of sync (second argument returns non zero).
  

•     E.g. if W = 100, and C = 5, this function will check the passcode
  

•     against all One Time Passcodes between 5 and 105.
  

Code:

for(var i = counter - window; i <=  counter + window; ++i) {
        opt.counter = i;
        if(this.gen(key, opt) === token) {
            // We have found a matching code, trigger callback
            // and pass offset
            return { delta: i - counter };
        }
    }

Note that the for loop goes from counter - window, to counter + window. So if W was 100, it would be checking 200 values, not 100. Assuming that C means opt.counter in the docs, it would really be counting from -95 to 105.

When using Browserify the crypto library doesn't recognize SHA1 as an available hash algorithm on https://github.com/guyht/notp/blob/master/index.js#L30.

sha1 does work, however. Looking at node docs it seems that it should have been sha1 in the first place, but I'm not sure if this is platform dependent. Therefore it might be a good idea to use crypto.getHashes() to find a suitable algorithm.