akanass/rx-otp

HMAC-based (HOTP) and Time-based (TOTP) One-Time Password manager. Works with Google Authenticator for Two-Factor Authentication.

rx-otp's Issues

Generate TOTP that doesn't start with zero

Sometimes TOTP codes starts with zero like: 054878, It's not good for us
How can I prevent this?

browser version needed

version Using in IE,chrome,etc, is being needed

browserify version of jsopt

function hotp(key, count, digitLength,algimType) {
if(!algimType){
algimType='SHA-1';
}
var shaObj = new jsSHA(algimType, "HEX");
shaObj.setHMACKey(key, "TEXT");
count =count.toString(16);
if(count.length<16){
var tmpZero='0';
count=tmpZero.repeat(16-count.length)+count;
}
shaObj.update(count);
var hash = shaObj.getHMAC("HEX");
var offset = Math.abs(parseInt(hash.substr(38, 2), 16));
offset = (offset & 0x0F)*2;
var trucateValue = "0x" + hash.substr(offset, 8);
trucateValue = Math.abs(parseInt(trucateValue)) & 0x7FFFFFFF;
if (!digitLength || digitLength <= 0 || digitLength > 6) {
digitLength = 6;
}
var hotpValue=(trucateValue % (Math.pow(10 , digitLength))).toString();
var lengthDiff=digitLength-hotpValue.length;
if(lengthDiff){
var tmpZero='0';
hotpValue=tmpZero.repeat(lengthDiff)+hotpValue;
}
return hotpValue;
}

function totp(key, timeStampDifference, stepLength, digitLength,algimType) {
    if(!stepLength){
        stepLength=30*1000;
    }
    return hotp(key, Math.floor(timeStampDifference / stepLength), digitLength);
}

and about the jsSHA,you can find it by google 'jsSHA'

Serious failure in verification

Hey

Unless i'm hugely missing something, Ù2F.verifyOTP seems to have a significant flaw..

For example, with a base32_key of VALN YFSX VQNO DANY L3HQ AENO 5FKY 4FMV, U2F.verifyOTP accepts a valid code from my authenticator but it also accepts a low digit, such as 1, 2 or 3, with a delta between -1 and 1.

This doesn't seem to match the behaviour of other online TOTP validators.

Depends a vulnerable version of hoek

Depends on [email protected] > [email protected] > [email protected] > [email protected].
This version has a known vulnerability: https://nodesecurity.io/advisories/566. You can fix this by using a more recent version of joi.

After verifying one valid code with GA, all other subsequent verifications also return true for the same secret.

var check = OTP.googleAuthenticator.verify('123456', '0123456789ABCD', 2); // wrong code, returns null
var check = OTP.googleAuthenticator.verify('654321', '0123456789ABCD', 2); // right code, returns delta=0
// call after 10 seconds
var check = OTP.googleAuthenticator.verify('654321', '0123456789ABCD', 2); // right code, returns delta=0
// call after 30 seconds
var check = OTP.googleAuthenticator.verify('654321', '0123456789ABCD', 2); // right code, returns delta=0
// call after 5 minutes
var check = OTP.googleAuthenticator.verify('654321', '0123456789ABCD', 2); // right code, returns delta=0
// etc...

I found that manually setting the timestamp on GoogleAuthnticator.js line 248 fixes the problem, like so:

// before:
return TOTP.verify(_token, {string:self.decode(_secret)}, {window:_window});
// after:
return TOTP.verify(_token, {string:self.decode(_secret)}, {window:_window, timestamp: new Date().getTime()});

I believe it is being caused by joi caching the value of timestamp.