Crypto::Bcrypt::Password shadowing == operator

[anykeyh]

Crypto::Bcrypt::Password#== throws compilation error if equality is made with anything else than a String.

crystal/src/crypto/bcrypt/password.cr

Line 61 in 3c3d3e2

def ==(password)

Shouldn't be instead def ==(password : String) ?

Note 1: Not sure of the security implication of the change, e.g. being able to forge an equality check, so I didn't do any PR

[anykeyh]

Also, a bit off-topic, but it takes around 1 sec (without --release flags) to compute BCrypt on my Macbook core i7 with default parameters.

The number of turns by default sounds a bit conservative in my opinion, would definitely protect from brute force, but open your app to DDoS 😄 (see below)

ruby -e 'require "bcrypt"; require "benchmark"; puts Benchmark.measure{ 10.times{ BCrypt::Password.create("Hello") } }'

crystal eval 'require "crypto/bcrypt/password"; require "benchmark"; puts Benchmark.measure{ 10.times { Crypto::Bcrypt::Password.create("Hello") } }'

(edit: testing with --release flag works way better)

  10.times { BCrypt::Password.create("Hello") }'

  RUBY                 0.630000   0.000000   0.630000 (  0.625638)
  CRYSTAL (release)    1.460000   0.000000   1.460000 (  1.458953)
  CRYSTAL (no release) 11.990000   0.010000   12.000000 (  12.020243)

[straight-shoota]

Yes, Bcrypt::Password#== needs a type restriction to String in order to avoid shadowing the general Reference#==(other).

About the performance issue: Crystal's Bcrypt implementation is written in pure Crystal. It's not totally optimized and - as declared in the API docs - expected to be (currently) about 50% slower than mature C implementations (which are probably used by your Ruby example). This will certainly improve in the future.

Also note that you didn't configure any cost value, so the examples will use whichever default cost each implementation assigns. But unless using equal cost parameter, a performance comparison between different algorithms is total nonsense.