HoneyPot Captcha

[Jack_mcs]

1 hour ago, Chadduck said:

Another quickie regarding enabling the LOG TRACKER file

WHERE is it created and stored?

It's in the shops include directory and is named HoneyPot_log.  I apologize for not mentioning that in the docs.

[Guest]

57 minutes ago, Jack_mcs said:

Did you make a change or were just expecting something else? 

No, I didn't really know what to expect, so I posted the screenshot just to get your opinion.

Thinking about my create account page...I have disabled the telephone number field as being a requirement. 

It's there, but...you can take it or leave it.  I tried a new account with a phone number, and it still failed with captcha enabled.

Guess I'm wondering if whatever I did to disable it may be in conflict with the captcha code.  I'll take a closer look at that tomorrow.

For what it's worth, I haven't gotten a single fake account since installing this around noon today.  The spammers are definitely still trying...I'm getting loads of emails from the Log feature that say: 

11-04-2019: Denied due to numbers in a name

The attempts are obviously automated, as the IP addresses being used are generating these emails every 30 minutes like clockwork.  I have the time set between create account attempts at 30 minutes.  I may be perfectly fine without the captcha, but I will look at it some more tomorrow.

Thanks for your great work, @Jack_mcs

- Andrea

[Jack_mcs]

30 minutes ago, puggybelle said:

It's there, but...you can take it or leave it.  I tried a new account with a phone number, and it still failed with captcha enabled.

I don't think so but maybe. The code checks most of the fields on the page. I put checks on some like birthdate since that isn't always enabled. I probably should have put checks on all of them. I suppose the code could be failing due to that but that part of the code is before the captcha code so I would think, the captcha wouldn't even display if that were the case. It would have to be tested to be sure.

I'm glad to hear it helped stop them.

I'm thinking about changing the code that records the IP to add it to the IP List. That would automatically ban that IP. The main problem I see with it is there isn't a way to edit that list other than manually doing so so I would have to add that. What do you, or others, think of having such an option?

[♥ecartz]

56 minutes ago, puggybelle said:

Guess I'm wondering if whatever I did to disable it may be in conflict with the captcha code. 

Not and get the error that you're getting in your log (the captcah error message). 

Now, what could have happened is that when you tried it with the session variable bug fixed, you actually got a different error in your log.  You might try creating another account with the session variable fixed and check your logs then, possibly with logging turned back to the original settings so you'll see the error logged without it being buried in other things.  I probably should have suggested that then. 

[Guest]

25 minutes ago, Jack_mcs said:

What do you, or others, think of having such an option?

I don't know.  Seems like when you block one they just come again from another and it never ends.

My IP Block list via cPanel is quite large already.  And I always worry that I may end up inadvertently blocking legitimate buyers from accessing my site in the future.

Guess it's a personal preference.  I love what Honeypot Captcha is doing as it is.  I wouldn't request what you're offering, but...that's just my two-cents.

- Andrea

 

[Guest]

27 minutes ago, ecartz said:

Now, what could have happened is that when you tried it with the session variable bug fixed, you actually got a different error in your log.

No offense, but I don't understand what you mean.

Try again after my previous session has expired?  I don't know what you mean.

- Andrea

[♥ecartz]

1 hour ago, puggybelle said:

I don't know what you mean.

1.  Make sure that you are using the code version with

$_SESSION['security_check'] = "$numero";

2.  Make sure that your logging is set back to the original level so that you aren't getting spammed with meaningless notices. 

3.  Make sure that you have the Maths captcha turned on. 

4.  Try to create an account. 

4.  Assuming it fails, go look in the logs and see if it is the same error (the captcah error) or a different error. 

If it is a different error, then you've at least made some progress.  You can move on to troubleshooting that instead. 

If it is still giving the same error, try changing the logging line in includes/functions/honeypot.php to

            WriteToLog(TEXT_CREATE_ACCOUNT_CAPTCHA . ' /' . $_POST['security_check'] . '/' . $_SESSION['security_check'] . '/'); 

Maybe that will get you more information. 

[Jack_mcs]

10 hours ago, puggybelle said:

My IP Block list via cPanel is quite large already.  And I always worry that I may end up inadvertently blocking legitimate buyers from accessing my site in the future.

To be clear, I was referring to the list that Honey Pot keeps. I think you mean the one in the .htaccess file. It is possible to block a legitimate IP as you mention. But would any legitimate customer enter a name with more than two words or with letters in the phone field?

@ecartzis correct about the session name. To fix it, in the captcha.php file, change 

$_SESSION['check'] = $numero;

to

$_SESSION['security_check'] = $numero;

 

[Chadduck]

Jack

First before I forget - THANK YOU!!! 
I often forget to say that as I move onto the next module.

The Honeypot is stopping registrations like this one

First Name
What's the most convenient method to gain $79862 a month: 
https://make-1-btc-per-day.blogspot.co.uk?i=86

Last Name
What's the most convenient method to gain $79862 a month: 
https://make-1-btc-per-day.blogspot.co.uk?i=86

Those type registrations were being done 10 -15 times a day.

I do have a question though - Can anything be done regarding the registrations like these?
Customers    Date
Bobbiemof BobbiemofYV    11/05/2019 
Marina85waymn Marina85waymnMT    11/05/2019 
CarolPhove CarolPhoveIA    11/05/2019 
NovostroykiVolgogradDIx NovostroykiVolgogradDIxBN 11/05/2019 
Smocnat KaocnatLC 11/05/2019 
RandalJub RandalJubMD 11/05/2019 

Did I miss a setting? Do I need to set something?

BJ

Edited November 5, 2019 by Chadduck

[Jack_mcs]

20 minutes ago, Chadduck said:

First before I forget - THANK YOU!!! 
I often forget to say that as I move onto the next module.

I appreciate that but I understand how it is to forget to comment or mark a post as liked. I do the same myself at times.

 

22 minutes ago, Chadduck said:

I do have a question though - Can anything be done regarding the registrations like these?

If I understand your question, those examples are all for the date of birth field. If that is the case, the answer may depend on your version of oscommerce. In Frozen and Phoenix, the DOB is already checked in the create account file to make sure it is a numeric entry. I don't recall if older versions of oscommerce checked that or not but if your versions doesn't check it, that code should be changed.  It would not be something I would add to this addon since it should be handled by the stock code.

[Chadduck]

1 minute ago, Jack_mcs said:

If I understand your question, those examples are all for the date of birth field.

I am sorry if that was confusing...  That was a cut and paste from the administration page dashboard.  

The date was the date created since the dashboard only shows the First Name - Last Name and creation date.  

I probably should have indicated that and I do apologize.  BUT it seems that the bot is simply inserting the same first and last name with an additional alpha character or two.  The added characters are generally in upper case.

Again - THANK YOU my life has gotten much easier thanks to this mod.

[Guest]

When I initially turned on the error reporting in create_account.php I had so many errors, I think they may have 'hidden' what I'm seeing today.  I cleaned up all of my old errors and then took a shot at this again.

I swapped out the entries in captcha.php - turned on the error reporting in create_account.php - and tried again.

No account created, but I am seeing this onscreen:

Notice: A session had already been started - ignoring session_start() in /home/xxxx/public_html/includes/functions/honeypot.php on line 58

Notice: Undefined index: security_check in /home/xxxx/public_html/includes/functions/honeypot.php on line 60

Any ideas?

- Andrea

[Jack_mcs]

1 hour ago, Chadduck said:

I am sorry if that was confusing...  That was a cut and paste from the administration page dashboard.  

The date was the date created since the dashboard only shows the First Name - Last Name and creation date.  

No problem.

As for the name with the extra characters, there's no way to code for that. The code has to be able to determine an entry that is fake. While you can look at the names and be pretty sure they are fake, the code can't do that. If the extra characters are unique you could use the Bad Words option. I can't think of any legitimate entry for the create account page that would contain VV so if you add that to the Bad Words, an account that has VV in any of the fields would be blocked. But you could do that with the letters IA because a legitimate customers name might be Ian and he would be blocked.

I suggest you look at each account and see if there is some other indication that they are fake accounts. It may be possible to block them If there is something else the code can check for.

[Jack_mcs]

1 hour ago, puggybelle said:

No account created, but I am seeing this onscreen:

Notice: A session had already been started - ignoring session_start() in /home/xxxx/public_html/includes/functions/honeypot.php on line 58

There must be something with your server or shop settings causing this since others are not having a problem. Maybe this will help. In the includes/functions/honeypot.php file, find

        session_start();
 
        if (($_POST['security_check']) != $_SESSION['security_check']) {
            WriteToLog(TEXT_CREATE_ACCOUNT_CAPTCHA); 
            return true;
        } else {
            unset($_SESSION['security_check']);
        }	

and change it to

        if (! isset($_SESSION)) { 
            session_start();
        } 
        if (isset($_POST['security_check']) && ($_POST['security_check']) != $_SESSION['security_check']) {
            WriteToLog(TEXT_CREATE_ACCOUNT_CAPTCHA); 
            return true;
        } else {
            unset($_SESSION['security_check']);
        }	

 

[Guest]

That got rid of the first error I posted, but still no account creation and getting this now:

Notice: Undefined index: security_check in /home/xxxx/public_html/includes/functions/honeypot.php on line 61

Thanks for your continued help!

- Andrea

[Guest]

I installed this on my test site and it's working fine.

Now trying to figure out what the difference is between the two sites.  I'll post back when I figure it out.

Didn't change any of the original Honeypot files, either.

- Andrea

[Chadduck]

3 hours ago, Jack_mcs said:

It may be possible to block them If there is something else the code can check for.

My initial thought was elimination by country but since the account is created by data presented to the bot.  So that is out.

My next thought was abnormally long last name BUT in today's world with hyphenated names (e.g. Drake-Hollingsworth, Browskowski-Loveday, Rodriguez-Hernandez)

This is maybe a little outside the box but perhaps a hidden dropdown with three choices empty as the default, then bot and lastly spider.  Since it is an abnormal hidden field anything but the default selected would result in a denial.  

[Jack_mcs]

8 minutes ago, Chadduck said:

This is maybe a little outside the box but perhaps a hidden dropdown with three choices empty as the default, then bot and lastly spider.  Since it is an abnormal hidden field anything but the default selected would result in a denial.

I don't think that would be any different from the hidden field already in the code but maybe I'm missing the point.

[Jack_mcs]

Everyone - It was just pointed out to me that there is a line of test code present that shouldn't be there. To remove it, edit the includes/functions/honeypot.php file and remove this line:

echo 'cmp '.$item .' - ' .strip_tags($item).'<br>'; 

That should only show up if html exists in one of the fields. Since the create account page should use a function to get the field, that code should never be reached. But some versions of oscommerce may not be coded correctly so it should be removed.

[Chadduck]

14 hours ago, Jack_mcs said:

I don't think that would be any different from the hidden field already in the code but maybe I'm missing the point.

Jack

I apologize.  I was thinking I had read in the beginning of this topic that YOU  had discussed the AI bots.  It was not you but another user.  I was just trying to think outside of the box as to another verification check for those type of bots.

Again, apologies.  And thank you for not treating my comments /suggestions like  they were  unwanted  or silly.

BJ

[Jack_mcs]

53 minutes ago, Chadduck said:

Again, apologies. 

No needed at all. I would rather have the suggests than not have them.

[Chadduck]

On 11/4/2019 at 6:03 PM, Jack_mcs said:

The only pages that matter are the ones with forms on them. You need to add the two include statements to the ones you want to protect. See the install instructions for the contact us page and make those same changes for the password_reset page. The others have coded examples already. Each page with a form will have error checking for the form near the top. The verify statement goes there. The display statement goes above the submit button code for the page.

Jack

I finally got back to this for doing the password_reset.php.

As I was preparing to do it I was looking at the install instructions for the contact_us.php and then I stopped to send these questions.

I examined password_reset.php for the OSC 2.3.4  - it does not contain this line
    $actionRecorder = new actionRecorder('ar_contact_us', (tep_session_is_registered('customer_id') ? $customer_id : null), $name);

I also noticed that the include statement to be included reads as follows
    /*** BEGIN HONEYPOT ***/
    include('includes/honeypot/modules/honeypot_verify_contact_us.php');
    /*** END HONEYPOT ***/  

QUESTION 1

Since the $actionRecorder statement does NOT exist - can the include statement be inserted just after the require statement?  The file would then read as follows

 require('includes/application_top.php');

  require(DIR_WS_LANGUAGES . $language . '/' . FILENAME_PASSWORD_RESET);
    /*** BEGIN HONEYPOT ***/
    include('includes/honeypot/modules/honeypot_verify_contact_us.php');
    /*** END HONEYPOT ***/  

$error = false;

  if ( !isset($HTTP_GET_VARS['account']) || !isset($HTTP_GET_VARS['key']) ) {
    $error = true;

QUESTION 2

The include statement says to use the module file "honeypot_verify_contact_us.php" 

Does this remain "as is" or it necessary to create a "honeypot_verify_password_reset.php" file and correct it internally for the password_reset.php information?

Sorry if those are dumb questions BUT Honeypot has been working so well and has made my life so much easier that I am hesitant to change anything without verifying so that I do not BREAK anything.

BJ

[Jack_mcs]

The intention of the honeypot_verify_contact_us.php was meant to be a catch-all for all of the pages except create account. But I didn't revisit that code in this version since I was concentrating on the create account changes. Looking at it now, I can see some changes are needed but I think it will work.

I checked the file you mentioned but don't see the code you mentioned. In general, any page that submits a form will have a line like this

if ($error == false) {

There may be multiple lines like that. The verify line of Honeypot should go right above the one before the code that accepts the input .

Include the verify contact us file should work but any failures will report it is the contact us page where they occurred. That is not a problem with the code  but can be confusing.

For all such form pages, be sure to put the display line right above the submit button code and to check the page in the Honeypot settings.

Please give it a try and let me know if it doesn't work.

[tonymazz]

Hi Jack. Thank you for all of the many hours you put in to these addons!! 

 In reviewing this I noticed a define missing in the languages

define('FORM_REQUIRED_INPUT', 'Enter Total Here');

[Guest]

Hello, @Jack_mcs

includes/modules/honeypot/honeypot_verify_contact_us.php

Where is MODULE_HEADER_TAGS_HONEYPOT_CREATE_ACCOUNT_SECURITY_FAILURE defined?  I can't find it.

I suppose I'm also confused as to why it would say create_account instead of contact_us, too.

The Contact Us page is not working for me with captcha turned on.  It just reloads the page when I try to send the inquiry.

Using 2.3.4.1 CE

- Andrea