You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Your password is longer than bcrypt supports. (Note: bcrypt itself, not bcrypt-ruby.) Any input after 72 bytes is truncated anyway.
See #208 (comment) and the followup comments for more info. You should probably be restricting incoming passwords to under 72 bytes if this is a UX concern for you.
Here's a simple test case for rails has_secure_password that also throws the InvalidHash, as bcrypt appears to be called before the length validations run.
# frozen_string_literal: true
require "bundler/inline"
gemfile(true) do
source "https://rubygems.org"
git_source(:github) { |repo| "https://github.com/#{repo}.git" }
gem "rails", github: "rails/rails"
gem "sqlite3"
gem "bcrypt"
end
require "active_record"
require "minitest/autorun"
require "logger"
# This connection will do for database-independent bug reports.
ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:")
ActiveRecord::Base.logger = Logger.new(STDOUT)
ActiveRecord::Schema.define do
create_table :users, force: true do |t|
t.string :password_digest
end
end
class User < ActiveRecord::Base
has_secure_password
end
class BcryptTest < Minitest::Test
def test_invalid_length
user = User.new
user.password = "password"
user.password_confirmation = "password"
assert user.valid?(:create), "user should be valid"
user.password = "a" * 150
user.password_confirmation = "a" * 150
assert user.invalid?(:create), "user should be invalid"
end
def test_bcrypt_invalid_hash
user = User.new
user.password = "password"
user.password_confirmation = "password"
assert user.valid?(:create), "user should be valid"
user.password = "a" * 1000
user.password_confirmation = "a" * 1000
assert user.invalid?(:create), "user should be invalid"
end
end
As a follow-up, as some users are reporting this is fixed, I can confirm I'm still seeing this issue on 20.04 with bcrypt-ruby 3.1.16 on rails 6.0 and ruby 2.7.2.
I just caught this in our logs. From what I can gather, #255 fixes this, but is waiting for a release to be cut?
I don't think this issue is a big deal, but I just want to know if we should do some quick workaround for this (rare!) event, or just ignore it until we can grab an updated bcrypt-ruby version!
Activity
tjschuck commentedon May 12, 2020
Your password is longer than bcrypt supports. (Note: bcrypt itself, not bcrypt-ruby.) Any input after 72 bytes is truncated anyway.
See #208 (comment) and the followup comments for more info. You should probably be restricting incoming passwords to under 72 bytes if this is a UX concern for you.
jwcooper commentedon May 12, 2020
Sorry, I figured this was worth posting as it's a regression from my other systems.
That works just fine on Ubuntu 18.04, for example, even if it only uses the first 72 bytes.
tjschuck commentedon May 12, 2020
That's fair. I'll reopen the issue to document it, but the easiest/best solution is still probably going to be validating the input first.
jwcooper commentedon May 13, 2020
Here's a simple test case for rails has_secure_password that also throws the InvalidHash, as bcrypt appears to be called before the length validations run.
thewalkingtoast commentedon May 20, 2020
I am also seeing this now after upgrading to Pop!_OS 20.04 LTS x86_64. New OpenSSL lib difference?
thewalkingtoast commentedon May 20, 2020
My issue was with @rajeevkannav's comment in #226 (comment)
TL;DR - Upgrade to bcrypt 3.1.13
adsteel commentedon Oct 8, 2020
Upgrading also solved my issue.
foreverLoveWisdom commentedon Oct 15, 2020
Upgrade to
bcrypt 3.1.16does solve my problem.My OS: Ubuntu
20.04Rails:
4.1.0Ruby:
2.1.1jwcooper commentedon Dec 14, 2020
As a follow-up, as some users are reporting this is fixed, I can confirm I'm still seeing this issue on 20.04 with bcrypt-ruby 3.1.16 on rails 6.0 and ruby 2.7.2.
gmbollati commentedon Apr 19, 2021
I have the wame issue whith rails 3.2.22 and ruby 2.2.1
my ruby gems is 2.6.14
Help :D
erikbrannstrom commentedon Mar 14, 2022
I just caught this in our logs. From what I can gather, #255 fixes this, but is waiting for a release to be cut?
I don't think this issue is a big deal, but I just want to know if we should do some quick workaround for this (rare!) event, or just ignore it until we can grab an updated bcrypt-ruby version!
tjschuck commentedon Mar 14, 2022
@erikbrannstrom I just cut and pushed
3.1.17which includes #255.erikbrannstrom commentedon Mar 21, 2022
@tjschuck Thanks a bunch! 🎉