Someone is creating new fake customers accounts

[InvincibleRecordings]

Somehow between Bruce installing the Phosphor Media Easy Account and some additional Bot Block code the problem has gone away.

[oliverands]

Any of you developer types interested in writing a module to add reCAPTCHA v3 to Miva? Looks like it's pretty slick and powerful without a negative user experience for real people.

https://www.google.com/recaptcha/intro/v3.html
https://developers.google.com/recaptcha/docs/v3

I would definitely be interested in a module that managed this for my site.

[alphabet]

I think Bruce is saying that the bot is a headless browser that hits the CGI endpoint with request headers and a post payload. The bot never actually visits the page.

It looks like the bot REQUESTS the ACAD page with a Customer_LoginEmail parameter (Password Recovery Email) and is looking for RESPONSE with a g.customer_invalid_addinfo.

If g.customer_invalid_addinfo is TRUE then the bot has a valid Customer_LoginEmail. If g.customer_invalid_addinfo is FALSE then a fake account is created - but that is just collateral damage to the bot.

I would check the User Interface > Error Message tab for 'The email address you entered is already in use.' to see if the bot captured anything.

[kocourek]

Since most bots try to fill in all form fields, we use a "honeypot" input field with a touch of JavaScript. The honeypot input is hidden with CSS, and listened to with JavaScript. If a value is entered into the honeypot we change the form submit location via JavaScript (a black hole). It's not a perfect solution, but has eliminated our spammy form submission issues, AND we do not need to use a Captcha.

[Bruce - PhosphorMedia]

Like I said...musing...it would be great to just be able to say, "We don't accept input unless its from a 'keyboard'" (And that would include voice-to-text etc since they trigger key-events.)

[alphabet]

a way to detect whether or not the data input received by CGI where indeed entered via a keyboard

I think that is the purpose of the CSRF token. Can InvincibleRecordings add the hidden field and make sure the 'Require CSRF Token for Customer Actions' is checked.

Still wondering if the 'Defer Empty Baskets' setting will affect this since the token is associated with the baskets array?

I see where you're heading with this, that he'll otherwise have to sift through the server logs for the bot IP and hope it's not proxied. And FWIW, just checked and req_addr is not a required HTTP header.

[Bruce - PhosphorMedia]

Well, Easy Contact has its own built in Bot/Spam protection, which to date, has not been compromised... but that's for Email Contact and not just blocking bots from any form which what I was fantasizing.

[lesliekirk]

Musing Theoretical Here.... I wonder if there isn't a way to detect whether or not the data input received by CGI where indeed entered via a keyboard...for example, lets say you do a basic de-encryption of CGI data before processing it...and that data gets encrypted AS the user enters data via the keyboard...not sure how you'd hide the crypt-salt though seeing as how you'd have to do this at the DOM level...but it would be cool if you could basically prevent all bot efforts. (Of course, this would kill auto-fill...but i notice more and more sites are using "no autocomplete" anyway.

Perhaps a more relevant musing, since there may be inquiring minds that might like to know, will your Easy Contact module resolve this issue?

[Bruce - PhosphorMedia]

Musing Theoretical Here.... I wonder if there isn't a way to detect whether or not the data input received by CGI where indeed entered via a keyboard...for example, lets say you do a basic de-encryption of CGI data before processing it...and that data gets encrypted AS the user enters data via the keyboard...not sure how you'd hide the crypt-salt though seeing as how you'd have to do this at the DOM level...but it would be cool if you could basically prevent all bot efforts. (Of course, this would kill auto-fill...but i notice more and more sites are using "no autocomplete" anyway.

[alphabet]

Another idea is to pass the bot ip as a hidden field on the LOGN Create Account form and email it from the ACAD page.

On the LOGN Create Account form add:

<mvt:assign name="g.remote_addr" value="s.remote_addr" />
<input type="hidden" name="bot_ip" value="g.remote_addr" />

On the ACAD page add:

    <mvt:assign name="g.to_email" value="'YOUR_EMAIL'" />
    <mvt:assign name="g.from_email" value="'YOUR_EMAIL'" />
    <mvt:assign name="g.subject" value="'Bot IP'" />
    <mvt:assign name="g.message" value="'Bot IP: ' $ g.bot_ip />

    <mvt:do file="g.module_library_utilities" name="g.email_sent" value="SendEmail(g.to_email,g.from_email,'',g.subject,'',g.message)" />

[alphabet]

I'm hoping that the LOGN Create Account form submits and uses the customer's register_email input to create the account.

I think that the LOGN action responds with the ACAD so the user can further enter their address.

If the ACAD has access to g.Customer_LoginEmail it can log the bot_ip.

Otherwise, the bot is gone.

[lesliekirk]

I'm not sure if this will work but create a custom customer field with code 'ip'.
Then paste this snippet on the ACAD page.

<mvt:assign name="g.remote_addr" value="s.remote_addr" />
<mvt:item name="customfields" param="Write_Customer_Login( g.Customer_LoginEmail, 'ip', g.remote_addr )" />

I don't think this is happening on the ACAD Page. The Shadows ReadyTheme has an abbreviated account creation on the LOGN screen.

[alphabet]

I'm not sure if this will work but create a custom customer field with code 'ip'.
Then paste this snippet on the ACAD page.

<mvt:assign name="g.remote_addr" value="s.remote_addr" />
<mvt:item name="customfields" param="Write_Customer_Login( g.Customer_LoginEmail, 'ip', g.remote_addr )" />

[lesliekirk]

We have reCAPTCHA available if needed on the payment page but no where else. I think we are removing the "Create Account" page. I am first going with the Module approach and see if that ends the issue. But my hosting company did way they could block the IP address if I knew what it was. Does the MIVA admin have some place that can be found?

The IP address of the spammer? Only if it's collected. On a side note to the reCAPTCHA - I wonder if you could do a view source of the page it appears on (at checkout) copy the code and place it on the customer-log-in.html page? Just thinking out loud...

[InvincibleRecordings]

Does Bruce's module replace the abbreviated Create Account on the login page? I had forgotten about that option in Shadows.

Question - have you set up the Payment Settings reCAPTCHA? I wonder if there is a way to add it to the Customer Log In page?

https://docs.miva.com/reference-guid...

We have reCAPTCHA available if needed on the payment page but no where else. I think we are removing the "Create Account" page. I am first going with the Module approach and see if that ends the issue. But my hosting company did way they could block the IP address if I knew what it was. Does the MIVA admin have some place that can be found?