nevins-b / javascript-bcrypt Goto Github PK

What steps will reproduce the problem?
1. run multiple overlapping hashpw on different instances

Please provide any additional information below.

the fix is changing

obj = this

to 

var obj = this 

here in crypt_raw:

rounds = 1 << log_rounds;
  one_percent = Math.floor(rounds / 100) + 1;
  this.init_key();
  this.ekskey(salt, password);

  obj = this;  <------- HERE accidental Global use
  var i = 0;
  setTimeout(function(){
    if(i < rounds){
      var start = new Date();
      for (; i < rounds;) {

What steps will reproduce the problem?
1. Download the jsBCrypt-v2.1.zip file
2. Run test.html
3. compare results with another bcrypt implementation

What is the expected output? What do you see instead?
 Expected to get a hash which matches other bcrypt implementation hashes with identical salts

What version of the product are you using? On what operating system?
 2.1 on Mac OS X 10.6.7 with 5.0.5 (6533.21.1)

Please provide any additional information below.
 Issue seems to be resolved when you replace the contents of the included test.html with the  hosted test.html. The hosted test.html does produce a true result.
See DIFF output attached.

So, if someone wants to use jsBCrypt on their own website, most likely the 
first thing they'll do is go to 
https://code.google.com/p/javascript-bcrypt/downloads/list and download 
jBCrypt-v2.2.tar.gz.

That library depends on the Clipperz JavaScript Crypto Library, which is 
licensed under the AGPL. I'm not a lawyer, but I'm pretty leery of any AGPL 
code - I'm not sure if jsBCrypt can be BSD-licensed if it includes an 
AGPL-licensed library. I think jsBCrypt would be considered a "derivative 
work", and therefore must be licensed as AGPL (or maybe some other compatible 
license? Not sure there).

On the other hand, if you look in the source, it appears that the newest 
version of jsBCrypt instead depends on isaac.js, which is MIT-licensed. So, 
maybe the downloads section just needs to be updated? The demo page uses the 
version which uses isaac, so it appears to work.

That does have other implications, however. It looks to me like isaac.js uses 
Math.random() as a seed, which I guess could make jsBCrypt less secure? I don't 
exactly understand how the BCrypt algorithm uses the random number, so I don't 
know if that's really a problem.

Finally, it seems to me that bCrypt.js should probably have a copy of the BSD 
license at the top. As it is now, if I include bCrypt.js on my website, it 
doesn't indicate to the client what license it is under.

Sorry if that rambled a bit - hope that was clear, though!

What steps will reproduce the problem?
1. Try to run the Test page in IE

What is the expected output? What do you see instead?
Expect to see the hash, see Object Error instead.

What version of the product are you using? On what operating system?
jsBCrypt version 0.2, Win 7, IE 8.

Please provide any additional information below.
I "fixed" it for my use by replacing the brackets on the textbox strings with 
atChar() throughout the code. Firefox and Opera can use the brackets, treating 
the string as a simulated array, but IE will fail.

ops

javascript-bcrypt
jsBCrypt 
I am using v2.2 on Linux.


To reproduce the problem, run the following code:

var b1 = new bCrypt(),
    b2 = new bCrypt();
b1.hashpw('\u6e2f', '$2a$05$0000000000000000000000', function(hash1) {
    console.log(hash1);
    b2.hashpw('\u6f2f', '$2a$05$0000000000000000000000', function(hash2) {
        console.log(hash2);
        if (hash1 === hash2) {
            console.log('Hash collision !!!!');
        } else {
            console.log('Hashes are different, as expected.');
        }
    });
});

The result of the code above is:
   $2a$05$000000000000000000000uZFTs0iC2rTIcGXz5VM9Rg6ZA/slcl8i
   $2a$05$000000000000000000000uZFTs0iC2rTIcGXz5VM9Rg6ZA/slcl8i
   Hash collision !!!!


The two passwords give the same hash. I think this is because of the following 
loop appearing in method bCrypt.prototype.hashpw():
for (var r = 0; r < password.length; r++) {
    passwordb.push(this.getByte(password.charAt(r)));
}

This means an enormous number of hash collisions since only one of the bytes of 
any multi-byte utf8 characters in a password is considered.

This fixes a set of errors that users visiting the example.html page receive 
when visiting the HTTPS version of Google Code, e.g. 
https://javascript-bcrypt.googlecode.com/hg/example.html (for example, users of 
the HTTPS Everywhere plugin will run in to this issue)

The errors are fixed by loading all sources from Google's CDN with 
protocol-less URLs, which will enable the browser to use either the HTTP or 
HTTPS version.

What steps will reproduce the problem?
Initiation takes to long, becouse of PRNG.defaultRandomGenerator(), at least i 
think it's becouse ot if. It takes around 14 seconds on my computer before 
firebug prints "DEBUG: ### PRNG.readyToGenerateRandomBytes" an

What is the expected output? What do you see instead?
Being able to use jsbcrypt for login page the moment the page loads.

What version of the product are you using? On what operating system?
mar 7

Please provide any additional information below.
Is it necessary to use PRNG. Does generating salt from ie. 
$2a$<iterations>$md5(new Date().getTime()); is not enough to make bcrypt safe?

The bCrypt package contains MochiKit, which apparently also includes list of 
colors from tomato to springgreen Mochikit/Color.js:

    ...
    springgreen: "#00ff7f",
    steelblue: "#4682b4",
    tan: "#d2b48c",
    teal: "#008080",
    thistle: "#d8bfd8",
    ...

Now it's cool and all. But I don't think you should include anything not 
required in bcrypt implementation. I'm trying to figure out how to strip 
everything useless away, and possibly minimizing this implementation to single 
file.

What steps will reproduce the problem?
1. Run test page in IE and choose rounds greater than 5 in my case.


What is the expected output? What do you see instead?
Expect to see the hash. I get repeated dialog prompts asking if I want to stop 
the script. Eventually the script finishes as long as I don't stop it.

What version of the product are you using? On what operating system?
jsBCrypt version 0.2, Win 7, IE 8.

Please provide any additional information below.
This is not an issue with jsBCrypt per se, jsBrcrypt is performing as expected. 
It is because Microsoft IE default behaviour is to constantly prompt a users 
after 5,000,000 lines have executed. IE thinks it may be stuck in a endless 
loop. 

The loop that causes the issue is in bCrypt.prototype.crypt_raw:

for (i = 0; i < rounds; i++) {
    this.key(password);
    this.key(salt);
}

Rounds > 5 in my case is enough to see the issue. I could probably create a 
workaround sith setTimeout to get around this IE issue. 

Of couse the whole point of jsBcrypt is to be computational expensive, but I 
only opened this issue because had I known about the IE problems beforehand it 
would have saved me a lot of time and trouble, perhaps knowing this can help 
someone else.

make global obj in crypt_raw local