Is the order of the equality operator important in Ruby?

Question

I have used the bcrypt library in my Ruby program. I noticed that the order of the equality operator seems to be important. Depending on which variable is left or right of the '==' I get a different result. Here is an example program:

require 'bcrypt'
my_pw = "pw1"
puts "This is my unhashed password: #{my_pw}"
hashed_pw = BCrypt::Password.create(my_pw)
puts "This is my hashed password: #{hashed_pw}"

20.times{print"-"}
puts

puts "my_pw == hashed_pw equals:"
if (my_pw == hashed_pw)
  puts "TRUE"
else
  puts "FALSE"
end

puts "hashed_pw == my_pw equals:"
if (hashed_pw == my_pw)
  puts "TRUE"
else
  puts "FALSE"
end

Regards schande

Answer 1

Yes, there is a difference.

my_pw == hashed_pw calls the == method on the my_pw string and passes hashed_pw as an argument. That means you are using the String#== method. From the docs of String#==:

string == object → true or false

Returns true if object has the same length and content; as self; false otherwise

Whereas hashed_pw == my_pw calls the == method on an instance of BCrypt::Password and passes my_pw as an argument. From the docs of BCrypt::Password#==:

#==(secret) ⇒ Object

Compares a potential secret against the hash. Returns true if the secret is the original secret, false otherwise.

Answer 2

This doesn't really have anything to do with equality. This is just fundamentals of Object-Oriented Programming.

In OOP, all computation is done by objects sending messages to other objects. And one of the fundamental properties of OOP is that the receiver object and only the receiver object decides how to respond to this message. This is how encapsulation, data hiding, and abstraction are achieved in OOP.

So, if you send the message m to object a passing b as the argument, then a gets to decide how to interpret this message. If you send the message m to object b passing a as the argument, then it is b which gets to decide how to interpret this message. There is no built-in mechanism that would guarantee that a and b interpret this message the same. Only if the two objects decide to coordinate with each other, will the response actually be the same.

If you think about, it would be very weird if 2 - 3 and 3 - 2 had the same result.

That is exactly what is happening here: In the first example, you are sending the message == to my_pw, passing hashed_pw as the argument. my_pw is an instance of the String class, thus the == message will be dispatched to the String#== method. This method knows how to compare the receiver object to another String. It does, however, not know how to compare the receiver to a BCrypt::Password, which is what the class of hashed_pw is.

And if you think about it, that makes sense: BCrypt::Password is a third-party class from outside of Ruby, how could a built-in Ruby class know about something that didn't even exist at the time the String class was implemented?

In your second example, on the other hand, you are sending the message == to hashed_pw, passing my_pw as the argument. This message gets dispatched to the BCrypt::Password#== method, which does know how to compare the receiver with a String:

Method: BCrypt::Password#==

Defined in: lib/bcrypt/password.rb

#==(secret) ⇒ Object
Also known as: is_password?

Compares a potential secret against the hash. Returns true if the secret is the original secret, false otherwise.

Actually, the problem in this particular case is even more subtle than it may at first appear.

I wrote above that String#== doesn't know what to do with a BCrypt::Password as an argument, because it only knows how to compare Strings. Well, actually BCrypt::Password inherits from String, meaning that a BCrypt::Password IS-A String, so String#== should know how to handle it!

But think about what String#== does:

string == object → true or false

Returns true if object has the same length and content; as self; false otherwise […]

Think about this: "returns true if object has the same length and content". For a hash, this will practically never be true. self will be something like 'P@$$w0rd!' and object will be something like '$2y$12$bxWYpd83lWyIr.dF62eO7.gp4ldf2hMxDofXPwdDZsnc2bCE7hN9q', so clearly, they are neither the same length nor the same content. And object cannot possibly be the same content because the whole point of a cryptographically secure password hash is that you cannot reverse it. So, even if object somehow wanted to present itself as the original password, it couldn't do it.

The only way this would work, is if String and BCrypt::Password could somehow "work together" to figure out equality.

Now, if we look close at the documentation of String#==, there is actually a way to make this work:

If object is not an instance of String but responds to to_str, then the two strings are compared using object.==.

So, if the author of BCrypt::Password had made a different design decision, then it would work:

1. Do not let BCrypt::Password inherit from String.
2. Implement BCrypt::Password#to_str. This will actually allow BCrypt::Password to be used practically interchangeably with String because any method that accepts Strings should also accept objects that respond to to_str.

Now, as per the documentation of String#==, if you write my_pw == hashed_pw, the following happens:

1. String#== notices that hashed_pw is not a String.
2. String#== notices that hashed_pw does respond to to_str.
3. Therefore, it will send the message object == self (which in our case is equivalent to hashed_pw == my_pw), which means we are now in the second scenario from your question, which works just fine.

Here's an example of how that would work:

class Pwd
  def initialize(s)
    @s = s.downcase.freeze
  end

  def to_str
    p __callee__
    @s.dup.freeze
  end

  def ==(other)
    p __callee__, other
    @s == other.downcase
  end

end

p = Pwd.new('HELLO')
s = 'hello'

p == s
# :==
# "hello"
#=> true

s == p
# :==
# "hello"
#=> true

As you can see, we are getting the results we are expecting, and Pwd#== gets called both times. Also, to_str never gets called, it only gets inspected by String#==.

So, it turns out that ironically, the problem is not so much that String#== doesn't know how to deal with BCrypt::Password objects, but actually the problem is that it does know how to deal with them as generic Strings. If they weren't Strings but merely responded to to_str, then String#== would actually know to ask them for help.

Numeric objects in Ruby have a whole coercion protocol to make sure arithmetic operations between different "number-like" operand types are supported even for third-party numerics libraries.

Answer 3

The expressions would be equivalent if both operands were, for instance, of type String. In your case, one operand is a String and the other one is a BCrypt::Password. Therefore my_pw == hashed_pw invokes the equality method defined in the String class, while hashed_pw == my_pw invokes the one defined in BCrypt::Password.

I have never worked with BCrypt::Password, but would expect that you get false for the former and true for the latter.

Answer 4

In Ruby you can override the equality method for a given class or instance:

class Test
  define_method(:==) do |_other|
    true
  end
end

Test.new == 'foo' # => true
Test.new == nil # => true
Test.new == 42 # => true

'foo' == Test.new # => false
nil == Test.new # => false
42 == Test.new # => true

Generally speaking, it's considered bad practice to override equality without making it symetric, but you sometimes see it in the wild.