HoneyPot Captcha

[cables24h]

I not want to be a game breaker here.
But for the address part, google seemed to took care of it as well.
Google: Autocomplete Address Form

I just want to point out that most of the problems are covered in so much ways and by so much people and company who offer solutions.

I perhaps stirred the pot a little here.
But i think in the end it the discussion was worth it.
I definitely noticed that what i mentioned gave some second thoughts.

Nothing of what i Sayed was to hurt anyone in one way or the other, or try to let them look bad.

I think with what i told, opened doors to other views.

There is a real difference in running a shop or a forum or a blog.
I understand , the quicker the process, no burdens in registration etc, could make the purchase of an item quicker.

But it is good to talk about it, and even more........... to listen what the other say or try to understand
 

I excuse to anyone who felt or thought i was or that i  am a disturbing factor. 


 

[cables24h]

Let me go back to what i was actual saying... get rid of a static page like:

- create_account.php
- contact_us.php
- tell_a_friend.php
- product_reviews_write.php

These are the pages targeted by bots.
These are the least interesting pages to show up in search engines.
And when eliminate these, it "perhaps" prevent most of the BOTS.

For sure , any protection could benefit your store.
But i think it is better to look at the root of the problem.

By given advice, i step out of this conversation.
 

[Jack_mcs]

3 hours ago, cables24h said:

Let me trow up an idea and let YOU and the rest either give it a go... or reject it by good argumentation.

This has nothing to do with this addon. Please do not post unrelated things in a support thread. It is discourteous to others trying to follow the thread.

[mhsuffolk]

Still getting these, followed by Password reset and then a contact us attempt which is being stopped by Honeypot.

They must have Java off as I have hard coded the create_account code to display UK as default hence Afghanistan appearing.

Suggestion, as Afghanistan is 1 could we create a country named "Select Country" and number it 0 using a SQL query.

You would then replace in create_account.php

        echo tep_get_country_list(NULL, 'required aria-required="true" aria-describedby="atCountry" id="inputCountry"');

With

        echo tep_get_country_list('country','0', NULL, 'required aria-required="true" aria-describedby="atCountry" id="inputCountry"');

 

Then get Honeypot to look for country 0 and then snag it?

Just a thought as this is a recurring pattern that could be exploited by Honeypot

Edited November 18, 2019 by mhsuffolk

[Jack_mcs]

2 hours ago, mhsuffolk said:

Still getting these, followed by Password reset and then a contact us attempt which is being stopped by Honeypot.

This will be stopped by the next version of HP since it would fail on the postal code entry. I plan to get it uploaded soon.

If you offer more than one country to your customers, I suggest installing one of the Country-State addons. It adds the select option, or you can preset it to a particular country, and it will change the states/provinces to match the chosen country. That probably won't make a difference with the spammers since they usually bypass the form and, I assume, set dropdowns to some figure, though maybe not. But it is a nice feature to offer to your customers and if it also stops the spammers that would be nice.

[cables24h]

On 11/16/2019 at 6:14 PM, Jack_mcs said:

This has nothing to do with this addon. Please do not post unrelated things in a support thread. It is discourteous to others trying to follow the thread.

At the end..............
You go figure it all have to do with it.

That you are doing THAT ( so what you do).
There is much room open for many others to tackle that.

To goal is to prevent.
To monitor ( what means storing form $_POSTS................ mwaaaaaaaaaaa , i think that is a most unwanted subject of the cause).
 

At the end............ if it is HoneyPot, a GUARDIAN SYSTEM, or google reCaptchaV2 or google reCaptchaV3 ( you tried v3?).

osCommerce users simply do not like to be spammed.
If put that first and can agree on that.
That would might be a step forward for the whole community. 

[dfr717]

I've used this module for a few weeks now and it's solved 99% of our Contact Us spam.

I just installed the last few upgrades and everything works except after some trial and error it seems the Create Account Check will not operate while the Math Captcha is enabled and vice versa. When they're both enabled the error report I get e-mailed back from honey pot says " 11-19-2019: Denided due to captcah " I noticed someone was having the same error a few pages back but it was never solved. Might be another piece to their puzzle.

I would like them both to operate at the same time because I think they would weed out most of the fake accounts I'm getting.

I am using OSC 2.3.4

Any ideas? 

Thanks

Edited November 19, 2019 by dfr717

[Jack_mcs]

2 hours ago, dfr717 said:

it seems the Create Account Check will not operate while the Math Captcha is enabled and vice versa.

Others are not having this problem so I don't know what it might be. Be sure you have tried the things mentioned previously for the problem. A new version will be released soon that may work better for you so you might want to wait on it.

[mhsuffolk]

On 11/15/2019 at 7:01 PM, mhsuffolk said:

Using v1.8
In my Phoenix test shop, Frozen live shop and Frozen back up test site I am getting the following behaviour.

1. Install module and all basic settings including pages create account, contact us and tell a friend appear in admin
2. Edit module to alter various settings e.g.check account, disallow letters and numbers etc
3. Save module. The settings have been retained but the list of enabled pages is empty.
4. Checked in the database and the relevant field is empty.
5. Uninstall module
6. Reinstall module and the pages reappear.
7. Edit module, save it and the pages have gone again.

I have worked round it by adding the pages manually in the relevant field in phpmyadmin

Still getting this problem.

I also have the issue that the maths captcha stops everybody, even legit sign ups, getting through create account. Switch it off and all is well.

[Mikepo]

@mhsuffolk

The problem maybe this:

When honey pot finds an issue the user is taken back to the pre-populated create_account.php page so the user can correct the issue.  That is how it works, however the math question updates (without the user realising) and the form shows the previous answer which is now wrong.

The math question has to be answered again.

I must say that I'm using @burt math hook in frozen.  I did try the math option in honeypot, but as previously mentioned by others the math check in honeypot didn't work for me, it seemed to stop everything even with the right answer.

Hope this helps?

I ended up not using honeypot on live shops (I was just trying the module on test installations).  I just use gary's math hook on live shops and the problem with fake/spamming accounts have ceased.

[dfr717]

I went back through the installation and I did all the fixes that were posted previously and I don't believe anything is out of place. I'm finding when the Math Captcha is running by itself you can type whatever you want into the answer field and it'll be accepted, so when the bots are just filling every field out with gibberish they still get through.

 

[Jack_mcs]

8 hours ago, dfr717 said:

I'm finding when the Math Captcha is running by itself you can type whatever you want into the answer field and it'll be accepted, so when the bots are just filling every field out with gibberish they still get through.

The new version should fix the cpatcha problem. But just to be clear, you have to have the create account option enabled or all of the other create account checks, including the captcha, will be skipped.

[Jack_mcs]

A new version has been uploaded with these changes:

• Added a page in admin to find and delete suspected fake accounts. Original code supplied by @Chadduck .
• Added a page in admin to allow deleting an array from the tracking table and to view the log.
• Added an option to verify the submitted IP.
• Added an option to verify the postal code.
• Added an option to verify the state and country pair is valid.
• Added an option to check the time to submit a form.
• Added filesize to dislay of the cron job results.
• Changed the option for the Math Captcha to use an image or text.
• Changed the captcha.php file to include a missing parameter. Found by @puggybelle
• Changed the mysql command to work for non-standard database names. Found by @Chadduck.
• Changed the cron output to show the size of the file.
• Changed the IP List setting to include check TOR IP's.
• Changed the names used in the hidden fields in case hacker scripts scan for the common name of honeypot.
• Corrected a typo in the error messages. Found by @puggybelle.
• Corrected the session name in captcha.php. Found by @ecartz.
• Fixed problem with the cpatcha code so it now works correctly.
• Removed a line of test code that was overlooked.
• Removed the notification option. All emails are now sent using the log tracker option.

[Guest]

@Jack_mcs

I don't know what you did, but THANK YOU!  All works perfectly now, with captcha enabled, in both create account and contact us pages.

You're one of the best contributors of all time in this forum - thank you for all of your hard work and for sharing it with the community!

- Andrea

[mojohost]

I just installed 1.9 (first time), and I'm having a couple of problems. One, if I enable the captcha on create_account, I get this text showing on the form: FORM_REQUIRED_INPUT near the captcha input box. Is this intentional that I would see this next to the input box for the captcha? That's just a visual issue, however, no matter what I do, I cannot get an account to create. I keep receiving the message, The account could not be created. Please contact us for assistance. If I revert the create_account.php changes back to my default I can create accounts no problem. I also tried just now to set HoneyPot as least restrictive as I can to see if it was one of the settings by enabling them one by one, but at the least restrictive settings below I still get the account cannot be created error. Any ideas?

I just looked at the HoneyPot_log, and it's telling me this:  Denied due to a country - state mismatch.This IP has 15 violations. However, I have the Country/State match set to False, so it shouldn't be checking or denying. Not only that, but I've tried "Oregon" and "United States" along with "OR" and "United States", and I'm still getting the same error in the HoneyPot_log. Additionally, I would expect an error message on why they're being blocked rather than "The account could not be created. Please contact us for assistance". I don't want these to lead people to contact the shop if I can avoid it.

Installed Version: osCommerce Online Merchant v2.3.4.1

Edited November 24, 2019 by mojohost
Added info from the HoneyPot_log

[Jack_mcs]

4 hours ago, puggybelle said:

You're one of the best contributors of all time in this forum - thank you for all of your hard work and for sharing it with the community!

You're welcome and I appreciate the kind words.

@mojohostThe versions of oscommerce marked as 2.3.4.1 may not be the same version as others marked that way. So it might be that you are using the wrong version of files for your shop. For the FORM_REQUIRED_INPUT, check your create_account.php file and make sure that is used elsewhere in the file. Whether it is or not, you can edit the includes/honeypot/modules/honeypot_display.php and change this

                 FORM_REQUIRED_INPUT . '				 
               </div>

to this

               '</div>

For the problem with creating the account, try enabling the Honey Pot module but set the "Create Account Check" option to false. That disables all of the create account checks. If you can't create an account at that point, then it is probably something to do with the changes to the create account page.  Try using the included one as a test. It won't have any changes you may have made to yours but if it works, then it means something in your file is causing a problem with HP.

For the message that displays, that is deliberately worded that way - notice it does not have a link to email you. The idea is that if an account can't be created due to HP, then it is presumably not a legitimate account. It would not be a good idea to tell a hacker that his attempt failed because he typed in something incorrectly. Legitimate customers shouldn't see that message unless they make some mistake that violates one of the rules. But in that case, the normal code should display a message. You can change the message to what you want in the HP language file. 

[mojohost]

@Jack_mcs

Thanks for the reply. I'm using the official 2.3.4.1 (not BS or other community versions). I'll try setting to false and let you know the results. I appreciate the detail about the wording as well. I know it works the same with logins and not telling them specifically which item is incorrect. I wasn't sure if it was due to the issue or by design. I did notice that the instructions reference changing a line that mentions the create_account.php file directly whereas my version uses the variable FILE_CREATE_ACCOUNT instead.

Edit: I set Create Account Check to false, and I was able to create an account no problem. I think it should be a flag to the issue that the log is telling me that it's failing the state/country check even though I have state/country check set to false. This implies a problem with the addon at this point rather than my create_account.php file. One, the state and country match and two, I have it set to false so it should be ignoring it regardless of a match or not. Honey Pot shouldn't be failing the state/country match when it's set to false.

Edited November 25, 2019 by mojohost

[Jack_mcs]

10 hours ago, mojohost said:

Honey Pot shouldn't be failing the state/country match when it's set to false.

I just tried it here. The country-state error didn't get logged when that setting was off and a wrong combination was mentioned.

[dfr717]

I'm getting this error now, never had anything like it in the previous updates. 

Parse error: syntax error, unexpected ')', expecting T_PAAMAYIM_NEKUDOTAYIM in /usr/home/.../public_html/catalog/includes/functions/honeypot.php on line 261

PHP Version 5.3.29 if that helps.

[valquiria23]

23 hours ago, Jack_mcs said:

A new version has been uploaded with these changes:

I really like this addon. thank you very much for supporting OSC @Jack_mcs !!

You deserve recognition not only for this cool addon but also for the excellent support you give!

Edited November 25, 2019 by valquiria23

[Jack_mcs]

48 minutes ago, dfr717 said:

I'm getting this error now, never had anything like it in the previous updates. 

It's an error that is saying there is a problem with the code. It displays in Polish since that is how 5.3 was coded. I don't have a 5.3 shop set up to test with but I think the following will fix it. Find this line in the file mentioned

    if (! empty(MODULE_HEADER_TAGS_HONEYPOT_VERIFY_TIME_TO_SUBMIT)) {
    
 

and change it to

    $var = defined('MODULE_HEADER_TAGS_HONEYPOT_VERIFY_TIME_TO_SUBMIT';
    if ($var && ! empty($var)) {  

 

[dfr717]

Yes! Awesome, thank you. Really appreciate everything you're doing, love the way everything works now too.

The fix you pasted is missing a " ) " but that fixed it.

$var = defined('MODULE_HEADER_TAGS_HONEYPOT_VERIFY_TIME_TO_SUBMIT');
    if ($var && ! empty($var)) {  

Thanks again!

[♥ecartz]

I think that should be

    $verify = 'MODULE_HEADER_TAGS_HONEYPOT_VERIFY_TIME_TO_SUBMIT';
    if (defined($verify) && ! empty($verify)) { 

Otherwise it still wouldn't work if the value was there. 

[mojohost]

8 hours ago, Jack_mcs said:

I just tried it here. The country-state error didn't get logged when that setting was off and a wrong combination was mentioned.

This is going to be a weird one. I think this was caused because I had previously emptied my countries table and manually added back just United States and Canada from within the admin interface. I reverted that change earlier today with a database restore (that was the only change), and now when I tried to create the account it worked without issue. So, for reference, if someone has messed with their list of countries via the database, that might potentially cause the country/state issue regardless of the setting in Honey Pot.

Edited November 25, 2019 by mojohost

[dfr717]

18 hours ago, ecartz said:

I think that should be

    $verify = 'MODULE_HEADER_TAGS_HONEYPOT_VERIFY_TIME_TO_SUBMIT';
    if (defined($verify) && ! empty($verify)) { 

Otherwise it still wouldn't work if the value was there. 

That code also gave me another error.

I believe the previous fix just resolved the 'Parse error' but the function itself doesn't actually work. I set the time to 60 seconds and I was able to make two accounts in less than 30 seconds, the second account shouldn't have been able to be created since the form was submitted twice from the same ip, correct?

Honestly, without this setting properly functioning the module is still keeping out all of the spam accounts that have been attempted since I got it up and running.