Jump to content

Recommended Posts

1 hour ago, JcMagpie said:

Simply add Google reCAPTCHA  along side honeypot and you will stop 99% of these fake accounts.

Here there is a compromise.
Now it is the job to put it in oscommerce with a click and GO.

reCaptcha is there.
HoneyPot is there.

How can put in in osCommerce without change a single line of core code?
What is need to allow BOTH kind of protection into osCommerce and keep EACH as an individual module, still............ somehow..... ( not osCommerces problem), work together.

All the others seem to manage THAT.
Just NOT osCommerce.................. how is that?
 

Share this post


Link to post
Share on other sites
4 hours ago, Jack_mcs said:

OK. When you have the details I mentioned please post them here and I will take a look.

image.png.b3db0d2750f18e539533a4335e74d248.png


Tony Mazz

Share this post


Link to post
Share on other sites
3 minutes ago, tonymazz said:

image.png.b3db0d2750f18e539533a4335e74d248.png

Stupid argumentation
You not VERIFY anything.
The address of the user is not verified.
for THAT NO legitimacy is conserved during the register process.
( this could be blamed to osCommerce itself or to module makers who chosen to cover this kind of failure)

 

Not a legit  resource to start with.

Share this post


Link to post
Share on other sites

Is it not here where it all starts from?
As soon when fill the form, osCommerce instantly log you IN.
Right?
you can put anything you want in the registation and it it is accepted.

WORSE........... you are instantly logged.......... right?

Do not blame me here as the MESSENGER.  

 

Funny stuff here is...................
In the end you only require:
Email: "put your email here"

Password: "put you password here"
As an addition:

Password confirmation: "Re-type your password here" 

That is ALL what THIS form SAY.

All the rest is CRAP, oscommerce NOT need it................. yeah it does..................... when checkout.
Why it not ASK WHEN............. yet osCommerce prefer the "pre-fill" the forms given on registration.

Let us open the discussion for it.
It give so much room/space for so much.

- registation procedure
- spam/honypot/reCpatcha options.

This is SERIOUS TALKS.
 

 

As a shop owner ........... you DO NOT NEED all the stuff inserted when a shop-user register.
You ONLY need it when that person makes a REAL purchase.

You SHOULD NOT CARE for the ones who register.
CARE FOR THE ONE WHO BUY!!!!!!!!!!!!!!!!!!!!
They put $$$$$$$$$$$$ income.

The hell who flood your DB.................
easy to remove them based on criteria.

 

The obvious here is you let spammers access your domain.
the good guys have access to whatever you allow them to.

Why allow someone who NEVER bought anything from you, gain access to anything that refers to a posting..
- reviews?


That is first check mark.
For the "contact_us" section.................. i think that is something you have to live with it as a shop-owner.

Funny thing is.............
Nothing of it affect your customer........ just you.
Nothing came in your mind................ that it is kind of part of the deal and you have to handle it?

I just try to figure............... sure if can prevent.

Just seems there is no absolution in it.

 

it is a fight with no ending.

 

to much effort into something not important.
Just let it go..............
No POT can stop it.

 

Better to login with just an E-mail and Password to osCommerce.
All the rest is detail.
And as a shop-owner............. it all comes down to a live purchase.

That is what matter to a shop-owner.

Share this post


Link to post
Share on other sites

My screenshot was from the admin side. We automatically send random generated passwords to the client via welcome email and try to collect minimal info at the time of checkout.

I thought about the email confirmation email, however over 75% of our clients want to just check out. Any delay in the checkout process can result in a lost sale. So that would not work.

3 minutes ago, cables24h said:

Why allow someone who NEVER bought anything from you, gain access

 I agree with you on this. Should any visitor even be creating an account without an actual purchase to start with? An option in admin could toggle that as an option for those that would.  In our case we are not interested in people signing up for a subscription or discounts as some commerce sites do. Perhaps, on the confirmation page the client is offered the opportunity to create an account  at the end of the checkout confirmation (admin can set default). So, create_account would not be offered as a standalone, automatic account creation would only occur after a bonafide purchase. And of course the admin would need to be able to create an account from admin side.

I will noodle this more.


Tony Mazz

Share this post


Link to post
Share on other sites
11 hours ago, tonymazz said:

I will noodle this more.

No need to Noodle.

What is say is right.


Your DB MIGHT be flood.
Who cares if it is a legit user or not.
He never buy anything.

Remove them from DB, no need of them.
Even the "legit ones"............. they not buy.
Useless.
Drop them.

A serious problem is the "contact_us.php" for a SHOP OWNER.
That is kind of pages should be somehow be protected.
 

 

Anyway..............
for me it does not matter.
There are authentication systems available.

It is UP to the shop-owner if want to implement them or not.

for me it is all a bias........... a CRAP.
There is nothing against it.
No reCaptcha
No HoneyPot

Just an attempt.
And all fall back to trustworthy customers/clients.

 

Kind of an old grocery shop in the old day's.
Stupid to think the internet can cover criminals.
 

Share this post


Link to post
Share on other sites

@tonymazzRegarding the account details you posted, unfortunately, there isn't anything shown there that would allow the code to identify it as a fake account. While a person can look at it and see that it is fake, from a coding point of view, it is legitimate since it has valid entries for an account.

I suppose a check could be added to see if the street address contained number and letters, or if just letters (which can happen) that it be at least two words. But that might be chasing a never ending list of possibilities.

Another check could be to see if the state and country match. Those details are in the database so it would not be difficult to check them. I will plan on adding this as an option.

Another check could be the post code. According to Wikipedia, the postal code of all countries that use one has at least one number in it.  I will plan on adding this as an option.

You don't mention if you are using the IP List option. If not, you should be. And make sure to set up a cron job for it or the list won't be useful.

If you can identify some common letters that are not normally used, you can include those in the bad words option. For example, the suburb has an entry ending in "vxqd". I can't imagine word from any country using that. The entries in the fields are probably just randomly created so adding words like this may not help, or only a little, unless you are seeing them used over and over.

As for sending emails, be sure you have the options set to block email addresses and url's in the forms. Depending on your version of oscommerce, there might be a setting to limit how often emails can be sent. By raising that number to something higher, like 30 minutes, it might make it difficult for the spammers to send out large numbers of emails.

That's all I can offer on this sort of problem. If you, anyone, can see something else that should be checked, please post it here.

 

Share this post


Link to post
Share on other sites
14 hours ago, tonymazz said:

I have tried reCaptcha and have had many real customers complain about it. With my own reCaptcha experiences, I must admit it is difficult to determine a storefront or traffic sign etc. It can be a real 'turn off' when registering at a site to make a purchase. I prefer to make our signup experience as hurdle and trouble free as possible.

ReCaptcha2 did not prevent these signups, btw. 

v3 does, though, and real people almost never see it. If you can live with having a logo somewhere on each page (not necessarily the floating in-your-face one) it's definitely worth considering.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (Phoenix).

here: on the official osc download page

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

You could compare a few things though.  In this example:  the country is Australia.  I don't believe that Australia has a state named Alabama (the US does have a state by that name).  I suspect that the postal code is not valid for Australia.  There are probably rules that an Australian could explain.  Wikipedia suggests that in Australia, all post codes are three or four digits. 

In the United States, all zip codes are either five numbers or five numbers followed by a hyphen followed by four more numbers.  So for a US zip code, you could check that the first five characters are numbers and the sixth character was a hyphen followed by digits in seven through ten.  I'm guessing that an Australian could provide similar rules there.  Perhaps add a postal code format regular expression to the countries table.  It could be '{.*}' by default but something like '{\A\d{5}(?:-\d{4})\z}' for the US and  '{\d{3,4}}' for Australia (none tested). 

Given how lazy spammers are, just filling in about ten formats should cover most of what they'll attempt:  Afghanistan, Albania, Algeria, Andorra, Antigua and Barbuda, Argentina, Australia, Canada, United Kingdom, and United States.  Perhaps later you might add Brazil, China, India, and Japan.  Like in the US, single country stores are probably common in those places.  And single country stores can more easily give the format used in their country. 


Always back up before making changes.

Share this post


Link to post
Share on other sites
16 hours ago, tonymazz said:

I have tried reCaptcha and have had many real customers complain about it. With my own reCaptcha experiences, I must admit it is difficult to determine a storefront or traffic sign etc. It can be a real 'turn off' when registering at a site to make a purchase. I prefer to make our signup experience as hurdle and trouble free as possible.

ReCaptcha2 did not prevent these signups, btw. 

Then you have not applied it correctly.

1) It will stop 99% of all fake accounts made by bot's ( nothing can stop human factory fake accounts)

2) Have installed on about 20 sites that were getting fake account problem has stoped on all sites. So yes it does work.

3) Your customers complain about you keeping them safe ( stupid cutomers no?) Also you can change recpatcha so customer is not required to do anything ( invisable cpatcha)

simply pick the one you are happy to work with.

image.png.cc7bd11599baabecf5c406f9845208da.png

 


 

Share this post


Link to post
Share on other sites
11 hours ago, cables24h said:

How can put in in osCommerce without change a single line of core code?
...
All the others seem to manage THAT.
Just NOT osCommerce.................. how is that?
 

Sure it can. Easy as 123.  


This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest Responsive osCommerce CE (community edition) here

Share this post


Link to post
Share on other sites

I appreciate all of the input and no, I have not tried recaptha 3 yet. I will give that a try on one of our sites.

As to the clients complaints, I do not get it either. Although there have been times that I have become frustrated with ReCaptch when I have to pick 3 images that match a topic like traffic lights, storefronts etc. The end result is that I realize it is for security and get on with it. It seems people are spoiled with instant purchases (ie PayPal, Amazon, eBay etc). I even have had a lot of clients complain about making up a password and then retyping it in, which is why we now send them a random password in the Welcome email. 

And yes, I do think some logic on Post Code format, as well as country/state mismatch, is a good idea for many reasons. I found these postal code patterns in HTML5 -- http://html5pattern.com/Postal_Codes to offer some initial guidance.

I did mitigate this issue (for now) after the dialogue yesterday gave me an idea. Since we really do not want or need signups until a purchase or quotation is made, I removed "create_account" from all of the pages as well as the login page. Renamed the "create_account" (changed it in filenames) and now it is only offered once something is in the cart and they hit "Checkout".

Perhaps this should be an option for future versions, to deploy without core code changes? A hook that would show create account (and on which pages) or not.

Thanks again all!

 

 


Tony Mazz

Share this post


Link to post
Share on other sites
4 minutes ago, tonymazz said:

I did mitigate this issue (for now) after the dialogue yesterday gave me an idea. Since we really do not want or need signups until a purchase or quotation is made, I removed "create_account" from all of the pages as well as the login page. Renamed the "create_account" (changed it in filenames) and now it is only offered once something is in the cart and they hit "Checkout".

A good solution :thumbsup:, go one step more and add guest checkout, this way no need to make account at all for those that object.


 

Share this post


Link to post
Share on other sites
5 minutes ago, tonymazz said:

I did mitigate this issue (for now) after the dialogue yesterday gave me an idea. Since we really do not want or need signups until a purchase or quotation is made, I removed "create_account" from all of the pages as well as the login page. Renamed the "create_account" (changed it in filenames) and now it is only offered once something is in the cart and they hit "Checkout".

Perhaps this should be an option for future versions, to deploy without core code changes? A hook that would show create account (and on which pages) or not.

I thought that was an excellent suggestion too.  I think Matt @ecartz is doing some work in this area and while it might be beyond the scope of his project it is probably worth bringing it to his attention.  Which I guess I just did.

Dan

Share this post


Link to post
Share on other sites
13 hours ago, Jack_mcs said:

Another check could be the post code. According to Wikipedia, the postal code of all countries that use one has at least one number in it.  I will plan on adding this as an option.

I found this snippet: https://gist.github.com/digvijay1985/b8015b58000acb27d663 for post code formats

<?php

$country_code="US";
$zip_postal="11111";
 
$ZIPREG=array(
	"US"=>"^\d{5}([\-]?\d{4})?$",
	"UK"=>"^(GIR|[A-Z]\d[A-Z\d]??|[A-Z]{2}\d[A-Z\d]??)[ ]??(\d[A-Z]{2})$",
	"DE"=>"\b((?:0[1-46-9]\d{3})|(?:[1-357-9]\d{4})|(?:[4][0-24-9]\d{3})|(?:[6][013-9]\d{3}))\b",
	"CA"=>"^([ABCEGHJKLMNPRSTVXY]\d[ABCEGHJKLMNPRSTVWXYZ])\ {0,1}(\d[ABCEGHJKLMNPRSTVWXYZ]\d)$",
	"FR"=>"^(F-)?((2[A|B])|[0-9]{2})[0-9]{3}$",
	"IT"=>"^(V-|I-)?[0-9]{5}$",
	"AU"=>"^(0[289][0-9]{2})|([1345689][0-9]{3})|(2[0-8][0-9]{2})|(290[0-9])|(291[0-4])|(7[0-4][0-9]{2})|(7[8-9][0-9]{2})$",
	"NL"=>"^[1-9][0-9]{3}\s?([a-zA-Z]{2})?$",
	"ES"=>"^([1-9]{2}|[0-9][1-9]|[1-9][0-9])[0-9]{3}$",
	"DK"=>"^([D-d][K-k])?( |-)?[1-9]{1}[0-9]{3}$",
	"SE"=>"^(s-|S-){0,1}[0-9]{3}\s?[0-9]{2}$",
	"BE"=>"^[1-9]{1}[0-9]{3}$"
);
 
if ($ZIPREG[$country_code]) {
 
	if (!preg_match("/".$ZIPREG[$country_code]."/i",$zip_postal)){
		//Validation failed, provided zip/postal code is not valid.
	} else {
		//Validation passed, provided zip/postal code is valid.
	}
 
} else {
 
	//Validation not available
 
}
?>

 


Tony Mazz

Share this post


Link to post
Share on other sites
1 hour ago, tonymazz said:

"UK"=>"^(GIR|[A-Z]\d[A-Z\d]??|[A-Z]{2}\d[A-Z\d]??)[ ]??(\d[A-Z]{2})$",

Looks good, but for OSC should UK be GB


OsC 2.3.4.1 CE Frozen   PHP 7.2   MySQL 10.1.36-MariaDB-cll-lve. Phoenix in development

Is your version of osC up to date? You'll find the latest osC community version (CE Phoenix 1.0.4.0) here.

Share this post


Link to post
Share on other sites

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

 


OsC 2.3.4.1 CE Frozen   PHP 7.2   MySQL 10.1.36-MariaDB-cll-lve. Phoenix in development

Is your version of osC up to date? You'll find the latest osC community version (CE Phoenix 1.0.4.0) here.

Share this post


Link to post
Share on other sites

@mhsuffolk I've just installed v1.8.  All ok here.  I'm adding the UK/GB postcode check too.  Seems to ok too!


osC BS gold live - osC CE in development (awesome)

Share this post


Link to post
Share on other sites
3 hours ago, mhsuffolk said:

Looks good, but for OSC should UK be GB

Yes.  The relevant line from install/oscommerce.sql is

INSERT INTO countries VALUES (222,'United Kingdom','GB','GBR','1');

That would have to be changed to make UK work as the key. 


Always back up before making changes.

Share this post


Link to post
Share on other sites
7 hours ago, tonymazz said:

Perhaps this should be an option for future versions, to deploy without core code changes? A hook that would show create account (and on which pages) or not.

What core changes did you make? 

As best I can see, the create_account link typically appears in content modules.  You can already disable those in admin without core changes.  I strongly suspect that there is a way to do at least most of this without core changes now. 

The thing that I might change, possibly not as part of my current project, would be to change what pages redirect to the login page.  That would make it easier to install a purchase without account App.  I.e. I'm thinking about moving the block of code that says

// if the customer is not logged on, redirect them to the login page
  if (!tep_session_is_registered('customer_id')) {
    $navigation->set_snapshot();
    tep_redirect(tep_href_link('login.php', '', 'SSL'));
  }

into a hook file.  I'm pretty sure that existing hook calls can be used. 


Always back up before making changes.

Share this post


Link to post
Share on other sites
14 hours ago, tonymazz said:

Perhaps this should be an option for future versions, to deploy without core code changes? A hook that would show create account (and on which pages) or not.

Core code changes are not required for this addon in Phoenix. Where are you seeing that requirement?

Share this post


Link to post
Share on other sites
14 hours ago, tonymazz said:

I found this snippet: https://gist.github.com/digvijay1985/b8015b58000acb27d663 for post code formats


<?php

$country_code="US";
$zip_postal="11111";
 
$ZIPREG=array(
	"US"=>"^\d{5}([\-]?\d{4})?$",
	"UK"=>"^(GIR|[A-Z]\d[A-Z\d]??|[A-Z]{2}\d[A-Z\d]??)[ ]??(\d[A-Z]{2})$",
	"DE"=>"\b((?:0[1-46-9]\d{3})|(?:[1-357-9]\d{4})|(?:[4][0-24-9]\d{3})|(?:[6][013-9]\d{3}))\b",
	"CA"=>"^([ABCEGHJKLMNPRSTVXY]\d[ABCEGHJKLMNPRSTVWXYZ])\ {0,1}(\d[ABCEGHJKLMNPRSTVWXYZ]\d)$",
	"FR"=>"^(F-)?((2[A|B])|[0-9]{2})[0-9]{3}$",
	"IT"=>"^(V-|I-)?[0-9]{5}$",
	"AU"=>"^(0[289][0-9]{2})|([1345689][0-9]{3})|(2[0-8][0-9]{2})|(290[0-9])|(291[0-4])|(7[0-4][0-9]{2})|(7[8-9][0-9]{2})$",
	"NL"=>"^[1-9][0-9]{3}\s?([a-zA-Z]{2})?$",
	"ES"=>"^([1-9]{2}|[0-9][1-9]|[1-9][0-9])[0-9]{3}$",
	"DK"=>"^([D-d][K-k])?( |-)?[1-9]{1}[0-9]{3}$",
	"SE"=>"^(s-|S-){0,1}[0-9]{3}\s?[0-9]{2}$",
	"BE"=>"^[1-9]{1}[0-9]{3}$"
);
 
if ($ZIPREG[$country_code]) {
 
	if (!preg_match("/".$ZIPREG[$country_code]."/i",$zip_postal)){
		//Validation failed, provided zip/postal code is not valid.
	} else {
		//Validation passed, provided zip/postal code is valid.
	}
 
} else {
 
	//Validation not available
 
}
?>

 

careful - the country code for the UK is actually GB

Edited by BrockleyJohn
ok - you know already - sorry!

For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (Phoenix).

here: on the official osc download page

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×