Chrome sometimes autofilling "subtitle" honeypot

[smidwap]

We use invisible_captcha in our customer support form. The past couple of weeks, several customers have told us that they've been unable to reach us via the form. To my knowledge, we've never received similar feedback until now.

Based on the customers' description of the problem and my own testing, my hunch is that Chrome's autofill feature is sometimes filling in the honeypot's value. We use the readme's suggested subtitle honeypot.

Here's a video demonstrating the issue. After I selected an email from the dropdown, I used the console to check the honeypot, which has been filled with the U.S. state I live in (weird!).

Screen.Recording.2021-06-16.at.2.27.25.PM.mov

I don't believe changing the name of the honeypot matters. I played around with assigning different names to the text field, and Chrome continued to autofill the field regardless.

My solution for now is to redirect "spammers" back to the form and ask them to resubmit their ticket. By pre-filling the form with the previous submission's content (name, email, message), autofill shouldn't get used again, and the resubmission should succeed.

Still, not an ideal experience. I'm not sure what a better solution would look like, but I thought I would bring this issue up in case others are receiving similar head-scratching feedback from users.

By the way, I am using version 1.1.0. I didn't think upgrading to 2.0 would make a difference.

[markets]

Hi @smidwap and thanks for such detailed report! to be honest, dealing with the autocomplete="off" nowadays is still a mess and each browser acts differently (at least last time I checked, around 1 year ago).

That's really weird, I'm also using the gem in several sites and AFAIK no similar issues were reproduced. You can try to use the default "honeypots" (random generated at boot time), by passing no parameters to the helper: <%= invisible_captcha %>. You can also generate your custom set of default honeypots (config.honeypots << ['more', 'fake', 'attribute', 'names']). In theory, by using non-common input names the autocomplete should not fill the input.

Not sure how we can solve this automatically inside the gem... 🤔

[smidwap]

I don't see any automatic solutions either. If more developers run into this problem, it might be worth editing the readme to encourage people to build error-handling into their workflow. I had the default behavior turned on, which meant falsely-flagged spammers were shown a blank page with a 200 status code.

[kylefox]

I think something might have changed in Chrome recently — we've seen a massive increase in false-positives, almost all from Chrome. Autofill is my guess as well.

It looks like we're actually getting more false-positives than true-positives at this point. My plan is to use the on_spam: hook to flag the created user as possible spam rather than completely block them from signing up.

That's my only idea at the moment — I'd love to hear/brainstorm alternate solutions. I'm not sure how to even begin troubleshooting something like this 😕

[kylefox]

Update: after investigating further, it looks like the vast majority of spam-detection is due to spinner failures rather than honeypot failures. So my issue might be unrelated to this issue / autocomplete (though it's still curious that nearly all of the spinner failures are happening in Chrome only).

[markets]

hmm 🤔 I can't think of a reason @kylefox, the spinner "check" is quite simple:

1) create a "token" and store it in session:

invisible_captcha/lib/invisible_captcha/view_helpers.rb

Lines 20 to 22 in 35a7f4f

	if InvisibleCaptcha.spinner_enabled && @captcha_ocurrences == 1
	session[:invisible_captcha_spinner] = InvisibleCaptcha.encode("#{session[:invisible_captcha_timestamp]}-#{current_request.remote_ip}")
	end

2) add a hidden field with that value:

invisible_captcha/lib/invisible_captcha/view_helpers.rb

Lines 59 to 61 in 35a7f4f

	if InvisibleCaptcha.spinner_enabled
	concat hidden_field_tag("spinner", session[:invisible_captcha_spinner])
	end

3) Compare if value from hidden input and the one in session are the same:

invisible_captcha/lib/invisible_captcha/controller_ext.rb

Lines 75 to 77 in 35a7f4f

	if InvisibleCaptcha.spinner_enabled && params[:spinner] != session[:invisible_captcha_spinner]
	warn_spam("Invisible Captcha spinner value mismatch")
	return true

Maybe something related to the fact of running multiple Rails instances and this👇🏼 flag?

• secret: customize the secret key to encode some internal values. By default, it reads the environment variable ENV['INVISIBLE_CAPTCHA_SECRET'] and fallbacks to random value. Be careful, if you are running multiple Rails instances behind a load balancer, use always the same value via the environment variable.

[kylefox]

@markets Aha! That's a great clue, thanks! Our app runs on multiple Heroku dynos, and each dyno boots its own instance of the Rails application. So it's essentially the same setup as a load balancer. I'm going to try this again tomorrow and see if it improves things 🙏

Sorry for hijacking this thread!

[thebluber]

hey I'm experiencing the same autofilling issue here. I'm wondering whether there is a workaround available for example using autocomplete="new-password" like described here https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#the_autocomplete_attribute_and_login_fields

Has anyone tried it out?

[kylefox]

Funny timing — just yesterday I was dealing with autocomplete problems on a user profile form (not related to invisible_captcha) and it seems like Chrome's autofill has become quite aggressive. I tried autocomplete="off" on the input and form tags, as well as autocomplete="new-password", and neither worked.

What finally stopped Chrome from autofilling my form was setting autocomplete to a random string:

<%= form.text_field :first_name, autocomplete: SecureRandom.hex(3) %>

It looks like the invisible_captcha helper will pass autocomplete options to the underlying hidden input, so you should be able to pass autocomplete: 'new-password' or autocomplete: SecureRandom.hex(3). If that seems to work, maybe this library could explore changing the default autocomplete value to a random string?

[thebluber]

I ended up using the default honeypots with random field names and it seems to solve the problem with autofilling @kylefox thx for the suggestion never the less 👍

[btrd]

For me subtitle worked, Chrome didn't auto-filled it. I'm using invisible_captcha 2.0 and Chrome 96.

@smidwap What was your configuration? I'm gonna try to replicate it with https://www.browserstack.com

[smidwap]

I am using invisible_captcha 1.1 (didn't think 2.0 would make a difference since the bug appears to be with Chrome) with the default options like so:

class Marketing::TicketsController < Marketing::BaseController
  invisible_captcha only: :create, honeypot: :subtitle
end

In my view:

<%= form.invisible_captcha :subtitle %>

I just verified the problem still exists with Chrome 96. Chrome's auto-filling behavior may vary depending on the fields your form includes and what data Chrome has available to auto-fill (e.g. Chrome is auto-filling my U.S. state in the subtitle field).

Since I implemented the solution (redirect captcha failures back to the form) in my initial note, we have not received any complaints about difficulty reaching us through our support form.