Hello.
On our Magento website we are getting a lot of attempted transactions trying to be placed using dummy card details. Braintree have advised us to set up a honeypot in the checkout. Has anyone else done this? Looking around, there seems to be numerous extensions that protect contact/review/account forms, but not the checkout.
As a temporary solution we have disabled guest checkout, but if anyone has any other ideas we’d be grateful!
I’m familiar with the “honeypot” term, but I’ve not seen this implemented on a checkout. I guess the bot is adding a dummy address at the checkout in order to advance to the next page? I’m interested to learn how this works.
We’re using a one step checkout (Amasty) so it tries to fill out all the fields on the checkout page. None of the orders go through as the card details don’t match, but we can get anything up to 10 per minute at random times. The transactions are also for stupid items like £2 xmas cards and notebooks, it’s not like we sell expensive high-end electronics. That’s why Braintree have recommended a honeypot within the checkout - a field that a person wouldn’t see and therefore wouldn’t enter information in to, but a bot would.
Ok, I see. So, what does adding an extra field accomplish? I get that a human wouldn’t see it… But what would you do with the information input within the field?
Sounds like a perfect place to add a reCaptcha v3, if there’s something for that. I see the M2 core security feature doesn’t offer reCaptcha for checkout. But then again, if it did then I guess it wouldn’t necessarily work with the Amasty module.
Effectively entering information in the ‘dummy’ field would prevent the attempted transactions from going through to the Braintree payment gateway. In one night around a month ago we had nearly 1000 attempted transactions - which looks weird in our Magento admin when all of a sudden the sequential order numbers jump up! The transactions don’t register within Magento, but they must get assigned an order number as technically the transaction was attempted.
Re. Recaptcha, this is another thing that Braintree recommended, but adding a reCaptcha to a checkout is a big no-no as it’s more hassle for our genuine customers. Amasty also advised against it, as we also use their Google ReCaptcha extension to protect our Account Signup, Review and Contact forms.
reCpatcha v3 remains hidden and only challenges “dodgy” IPs/Behaviour.
Anyway, as for setting up a Honeypot. It seems pretty straight forward according to this article. Just create a dummy form for the bot. However, I imagine that would also mess with a customers’ form autofill.
Tricking Spambots with a Smarter Honeypot
It’s time to step up our game, programmers! Here’s a combination of spam thwarting techniques that makes a great spambot-proof form:
- Create a honeypot with the same name as one of the default fields. Make it look legit with a label. If you are using bootstrap, make it look perfectly legit with label and icon. We don’t want to alert the bot in any way that this field is special.
- Place the honeypot in the form in a random location. Keep moving it around between the valid fields. We don’t want the spambot writer to simply ignore the same field based on index.
- Rename your default fields to something random. Keep in mind you have to convert it back to its proper name on the server side. By naming the default fields to something random, the valid fields now begin to look like honeypots to the spambot.
- Add an expiration to your form. This will keep spambots from using the same fields and submitting the form later.
- Hide your form. You have to hide the honeypot to keep the valid users from filling it out. In my form, I hide the honeypot with JavaScript. It is still valid for you to hide this field with CSS. If you use CSS, your best bet is to use a class that contains a random word. In other words, if you call it “hide”, then the spambot author will pick it out easily.
Just a case of doing some custom development of the existing checkout.
It’s also possible that Cloudflare would pick up on this behaviour too, as their DNS blacklists “dodgy” traffic before they can even get to your site.
I went through this on M1 with different things. I was able to pick out something specific in the way they were doing it (ie, address, length of email, type, etc…) and then you can find a way to omit these types of results and make then invalid for the field. I’m sure it is all coming from the same place. Even block the ip range etc…
An update. I have installed Hungersoft Honeypot (free from their github page). As this doesn’t work on the checkout, I have disabled guest checkout and made having a customer account mandatory now. (I was contemplating doing this anyway - we have some customers that have placed multiple orders but just don’t bother setting one up). The honeypot is active on our account set up / password reset / review / contact form pages, and touch wood, it seems to have solved the problem.
Reading this page on github, it does appear to be an issue that Magento need to work on. I am least grateful that it isn’t just our site getting hammered!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.