[mod_rewrite questions]

Just now, requinix said:

Yeah, it's fine.

So your only problem with the URLs in my OP is that I was mixing concepts into the 3 slots I had, right?

[mod_rewrite questions]

@requinix,

 

1 hour ago, requinix said:

No regular user has ever cared about URLs. For a while people thought making them look fancy was important for SEO, but it isn't.

Your URLs should be something that a person can look at and not be afraid of. Like this page, it says "topic" (I am viewing a topic) and it has "mod_rewrite-questions" (that's the title). That's nice and reassuring. If it was just "/viewtopic.php?tid=310679" then that's not as nice or reassuring, but neither your web server nor Google actually care.

 

So having a super pretty URL is something that the average user won't care much about, huh?

 

If so, then maybe having everything look like this is a waste of effort?

Product Catalog

	www.mystore.com/shop/movies/list/
	www.mystore.com/shop/movies/gallery/
	

 

Product Details

	www.mystore.com/shop/movie-details/the-irishman/
	

 

Also, to your point above, is it the end of the world if I have a pretty URL with a query string on the end like....

	www.mystore.com/shop/movies/?view=list
	www.mystore.com/shop/movies/?view=gallery
	

[mod_rewrite questions]

@requinix,

Believe it or not, I don't use a smart phone.

So, dumb question, but on a smart phone, do you even see the URL?

And on a regular computer, does anyone even care about URL's anymore? (I've heard one person say that they don't matter anymore...)

[mod_rewrite questions]

3 minutes ago, requinix said:

What are you going to do if you need to support an item named List or Gallery? Don't mix concepts like this.

Well, there will never be a product category called "list" or "gallery", so I am safe there.

I am mixing things, because I don't have a way to take care of the presentation.  Ideally I would use Javascript to handle the change in presentation, but I don't know Javascript, and that will have to be for a later version.

 

3 minutes ago, requinix said:

It's okay to use query strings.There is absolutely nothing wrong with /shop/movies/?view=list. In fact there are some schools of thought that say the path portion indicates a resource and is not where you should be putting aspects of that resource's presentation.

The reason I am mixing "organization" and "presentation" is that i wanted to have a nice looking URL, otherwise there is no need to use regex at all.

Hmm...

Looks like in this particular case, I am sorta stuck unless I did something like this...

Product Catalog

	www.mystore.com/shop/movies/list/
	www.mystore.com/shop/movies/gallery/
	

 

Product Details

	www.mystore.com/shop/movie-details/the-irishman/
	

 

I just wanted to keep the /shop/movies/<movie-title> format...

😕

[mod_rewrite questions]

22 minutes ago, requinix said:

Try it and find out?

I'm just writing things out on paper to come up with a gameplan for my design, plus I don't have a way to test it right now.

 

Quote

Spoiler: no
Hint: []s are for individual characters.

Oh, right, I forgot.  Haven't actively coded PHP or regexs in like 3-4 years.

 

Quote

Maybe? You'll have to be more specific than that.

Okay, so I have been thinking about things while waiting for a response.

Here is what I want to do.

I am working on my e-commerce catalog and product details page.

For the catalog I need a way to tell my PHP what kind of look to present, i.e. either a list of items OR a gallery of thumbnails of the items.  And so I was going to have a URL like this...

	www.mystore.com/shop/movies/list/
	www.mystore.com/shop/movies/gallery/
	

 

And for my product details page, I want a similar structure like this...

	www.mystore.com/shop/movies/the-irishman/
	

 

So I need some help from my Regex to help me sort out these similar looking URLs, and this is what I have for a solution so far...

	RewriteRule shop/(.+)/(list|gallery)$  shop/product-catgory.php?category=$1&view=$2 [L]
	RewriteRule shop/(.+)/(.+)$  shop/product-details.php?category=$1&item=$2 [L]
	

 

So to my comment above, I am somewhat using my Regex to route which page things go to, because they have the same looking URL in either case, but but my Regex helps play traffic director.

Thoughts?

 

 

[mod_rewrite questions]

A few questions about mod_rewrites...

1.) If I want to determine if the URL ends with either "list" or "gallery", and then take appropriate action, does the code below look correct?

	RewriteRule shop/(.+)/([list|gallery])$  shop/catalog.php?category=$1&view=2 [L]
	

 

2.) Is it bad to use mod_rewrites to determine how your website branches?

For example...

	RewriteRule shop/music/(.*)$  go somewhere [L]
	RewriteRule shop/movies/(.*)$  go somewhere else [L]
	RewriteRule shop/books/(.*)$  go yet somewhere else [L]
	

 

 

[Secure PHP Hash]

2 hours ago, StevenOliver said:

Instead of "what's the most secure hash," your real question is "What's the best way to enforce a limit of 'n' customers per credit card."

I agree.

 

2 hours ago, StevenOliver said:

Most of the top people in this forum are geniuses, and you would have gotten (and hopefully will still get) some really good answers! (Even the largest companies want to know the answer to this.) I had some more thoughts on this, here are the 'facts' I came up with:

1.) You have no control over how many people are in a household, using the same credit card (picture a close-knit family of 12).

It's possible.

 

2 hours ago, StevenOliver said:

2.) Individuals may have several credit cards (as Requinix said) companies offer virtual credit cards (google "online virtual cards" and you'll see ads for "unlimited card numbers.")

I'm gonna try and call Citibank about this, and see if I can understand the mechanics better...

 

2 hours ago, StevenOliver said:

3.) You don't want to make your customers feel like they have to give blood and jump through hoops (you want signup to be easy-peezy).

I agree, but remember, at this point my checkout process is the same as any other e-commerce site.  I ask for the same information everyone else does, and my checkout process is more streamlined.

IF I had a business rule where it was a limit of 3 accounts per a given cardholder and/or credit card, then that might be slightly more inconvenient for someone during checkout, but I don't expect a lot of families of 12 becoming customers!  😄

 

2 hours ago, StevenOliver said:

4.) You don't know how your business is going to do yet (hopefully it'll do so well you won't care about how many people share, you'll be making so much money!).

Yet, I could be building a titanium-plated Titantic!!!!!!!!!!!!!!!!!!!

 

2 hours ago, StevenOliver said:

That being said, when someone signs up and pays (3rd Party Billing Company takes care of the logistics for you), you'll have a Customer ID number, as well as the customer's email address and phone number. Your website could say "Welcome to our service and we're thrilled you're a customer! For the best service, please provide a phone number we can send a one-time 6 digit security pin." Then, when they type that PIN into their browser, they can choose whether to store it as a cookie so they don't have to enter it each time. Voila! Now you can monitor visitor's usage based on IP Location, user_agent, phone number, PIN, and their email -- all without having to store (or even know) part or all of their credit card number.

So what is that accomplishing?

It helps me prove that I have their real phone #?

I'm not sure typing the code into my website does much as far as their location, because they could be using a VPN or at the library.

But a validated phone # would be golden.

Not I don't recall, but I think "Billing Tele #" can be used to validate someone with Authorize.net.  (A working phone is pretty much required to open a bank account or credit card in the U.S., and banks/credit card providers are vigilant about making sure they have working #'s for compliance reasons.)

 

2 hours ago, StevenOliver said:

Then, you can watch that info as your business builds. You may end up not really caring about a little 'sharing' here and there. But if you find one of your customers is up to something suspicious (e.g. simultaneous logins from different IP locations), you can do the "Due to unusual activity, we need to send you a new PIN to your phone" thing.

There is a service - I forget it's name - that allows you to send text messages and phone calls from your website.  It's mainly used for two-factor log ins, but I could use that service for what you are suggesting.  of course, that is a whole new complicated thing to learn - assuming I could even figure out how to do it.  And that would have to definitely be a v2.0 or v3.0 feature.

 

2 hours ago, StevenOliver said:

Given there are a zillion workarounds to thwart all the above, I think this is as best as you can get. I would definitely have liability insurance that covers data breaches, and I would still definitely have a bonded security company build the up-to-date secure code to encrypt what needs to be encrypted, and hash what needs to be hashed (e.g. passwords only get hashed, they never NEVER should be encrypted and stored). Even if the business doesn't work out, it would still be fun to read and reverse engineer the state-of-the-art encryption code they build for you. And, at the very least, you'll be able to put all your coding skills to work: php, databases, mailing pin codes to phone numbers (making sure the PINs are single use and don't get duplicated), cookies, debugging, layout and design, etc., etc., all the stuff that makes life fun -- especially these days!!!

Yeah, I certainly have bitten off more than I can chew trying to build my own website, my own ecommerce site, and start my own online business!!

 

[Secure PHP Hash]

4 hours ago, kicken said:

Nope, not a valid assumption.  From privacy.com:

Using their service it sounds like you can just enter whatever billing info you want.  Doesn't have to be your real info.

It looks like these "virtual" credit cards that Requinix mentioned are really "pre-paid" cards.  

From privacyworld.com...

"Your card is not a US based credit card, it falls OUTSIDE US jurisdiction! Regardless of that, you can still purchase products on-line in USD though your purchases will automatically be converted into Euro's for accounting purposes."

Sounds like a great choice for the underground criminal types...

Okay, so I am learning something new here, and definitely a topic that I need to learn more about!

In the mean time, if I had to guess, I am sure there are ways to block out such cards and cardholders by how I set up my merchant account.  Furthermore, as I mentioned above, nothing is stopping me from suspending an order or account, until I speak with the customer and get some reassurance who I am dealing with.

 

4 hours ago, kicken said:

Now what about the corporate/non-profit group that wants all their employees to have an account and pays for them using a single corporate credit card?  Uh oh, they can't, or you have to up your limit again to however many employees they have.

Based on my website, I don't know that it would attract corporate clients, BUT if it did, I could simply have a note to call me for such cases.  (That is a pretty common way to handle such a scenario.)

Good point, though.

 

4 hours ago, kicken said:

Yes, having a bunch of accounts for a single card may be fishy and worth attention, but outright trying to deny it isn't really the best solution.  You add that fact as an input into your filtering system.  That combined with other data can then determine if an account might be trouble and then take action such as flag the account for manual review and/or shadow ban it

Okay, I agree that my best bet might be to handle things after the fact, manually, on the back end.

For example, I start having problems with user#1, user#401, and user #4001.  I can go into my merchant account and see the data for each transaction/cardholder, and if I determine they are all using the same credit card #, or have other similarities, then I can do more investigation and take action.

But as an IT guy, I would much rather automate things up front, so I can spend my time on more important things, like creating new content to help make me more $$$!

 

 

4 hours ago, kicken said:

Yes, because it's a silly restriction that doesn't effectively solve the problem.  It'll cause issues for legitimate customers and only be a very minor inconvenience for the real trouble makers.  For example you just side-stepped the whole stolen credit cards issue.  Even your relaxed name/zip code hash won't solve that because each card will have different details.

So let's step back for a moment at look at this from a 20,000 foot view....

1.) Don't you think a significant portion of people in online forums/comments to articles/etc have a pre-disposition to being troublemakers?

 

2.) In reality, how often is a given person going to buy multiple accounts for other people? 2-3 other people - sure.  But more than that?

 

3.) In my TOS, I will spell out that if you break X, Y, or Z conditions, OR you are generally disruptive to the online community, that management has the right to temporarily suspend or permanently suspend your account, and that NO REFUNDS will be issued.  All decisions will be final. By signing the TOS, you agree to these terms.  So I think that covers me in the case of merchant disputes with credit card companies. From my experience with my own credit cards, if something is in writing, and you agreed to it, you are bound to it.  But nothing in writing, then you are SOL...

Thoughts?

 

4.) If you were an identity-thief, or  part of some crime syndicate, would you waste your time spending other people's money so you could buy subscriptions and post crap comments under the website's articles - similar to what the NY Times and Washington Post offer?

I do know that "Russian trolls" are a huge problem, and it seems to me that they would have all of the incentive in the world to use stolen cards and use them to push their misinformation/disinformation campaigns against the U.S.

This last reason is probably why I am trying to be aggressive about how I handle things.

 

But I certainly don't claim to have all of the answers!!

 

[Secure PHP Hash]

1 minute ago, gizmola said:

When I stated you don't need a billing address for a cc transaction that is because it is not input that is checked, thus it is optional.  Consider how cc's work in the world.  When you go to buy some gas for your car at the pump and insert the card, do they make you type in your billing address?

When you buy gas, that is what is called a "Card present" transaction, and it requires less verification, because the assumption is that if you have the card, it is yours.

When you buy gas do you have to enter in your card's CVV code?  No, because it is a "Card present" transaction.

When you buy a PHP book on Amazon.com, do you have to enter in your card's CVV?  Yes, because it is a "Card Not Present" transaction.

And in Card NOT present situations, you as the merchant, have the ability to define how restrictive you want to be.  (Authorize.net DOES allow you to check the Billing Address when a transaction is submitted.) 

 

 

1 minute ago, gizmola said:

Consider the many ways that the same address can be entered.  Any matching that might be done on address would be fuzzy at best.  

Again even with the same address (and I'll assume you would uppercase the input, because any variation of even letter case generates a different hash)  I can vary my input slightly to get around your mechanic some number of times.  

Bob Smith
232 River View Lane
Grand Rapids, MI 83293

Robert Smith
232 River View Ln
Grand Rapids, MI 83293

Robert Smith
232 River View
Grand Rapids, MI 83293-3233

Robert Smith
232 River VW
Grand Rapids, MI 83293-3233

Yes, all valid examples to make your point.

I believe the way that Authorize.net does it is that it primarily focuses on the number portions, so "232", but I cannot say with absolute certainty.

Also, I haven't looked at their user manual in over 2 years, so this is a bit fuzzy.

 

Either way, remember that it is "I" that would be capturing certain parts of the checkout data and using them moving forward.  So the way Authorize.net does things, and the way I might do things is going to be different.

In fairness, your example above definitely demonstrate your point, but for what I am trying to accomplish, consider this...

a.) In every example above, it is the same "Robert Smith"

b.) all in "Grand Rapids"

c.) same state of "MI"

d.) same 5-digit "Zip Code"

e.) And I suspect a lot of other information would be the same too (e.g. billing phone #)

Why?  Because banks/credit card companies do an enormous amount of vetting before they give you a bank account/credit card.

So while Requinix can have a million "virtual" credit card numbers, the reality is that he is VERY limited in how much he can change his personal information.

Consider "Know Your Customer (KYC), Customer Due Diligence (CDD), Anti-Money laundering (AML) and many other fedral laws/regulations/guidelines.

Unless you are a member of organized crime, you cannot easily have numerous names/addresses/phones, so certain common pieces of data will tie back to a given person.

Criminals get very creative, but I'm just trying to keep "honest people honest".

 

1 minute ago, gizmola said:

Now I don't think people are going to do this to try and get around your system.  Quite frankly I don't think any legit user who you just banned (and I would think you would need to probably refund at least the remaining portion of their fee or likely face legal challenges)  is going to turn around and try to sign right back up again.

Okay, duly noted.

 

1 minute ago, gizmola said:

Won't happen, so what is the point of creating a complicated and tempermental feature that isn't actually going to stop anyone who is persistent from resubscribing? As we've already established, all they would have to do is just use a different cc#.

Well, if they did come back, it would most likely be the same "Robert Smith" in "Grand Rapids, MI" unless this person is going to move and get a new credit card with a new address.

Now if some hostile person then used his/her relative's or friend's credit card, it would be harder.

And, yes, maybe I am "using an elephant gun to kill a mouse"!  *LOL*

 

1 minute ago, gizmola said:

That's not reverse engineering anything.  That is using intimate knowledge of system internals + a person's name, which in this scenario we are assuming your whole system database got dumped.  Yes it would be trivial for me to create a rainbow table of 10000 entries for every name in your database, all so that I could establish?  The last 4 digits of an unknown credit card?  

Now let's say that they got hold of this table or column of hashes with no idea what they were used for.  Can they be "reverse engineered?"  No.  Someone could try and generate a collision value, but that has no value in this use case.  It's just another set of input that will generate the same hash (or the original input, although if created randomly, the person running the computation wouldn't know).

Well, as an over-simplified example...  If they had suspicion I was storing "Cardholding Name" and "Last-4 of CC' in my hashes, they could create an enormous table and U.S. names - including "Robert Smith" - and when they got a hit, then they would know that "Robert Smith" + "9876" matched a hash, and thus they would know that that unknown hash matched known data.  Of course that would take ENORMOUS effort to do.

 

1 minute ago, gizmola said:

If you wanted a larger hash, you could jump up to sha256, but that sort of decision ought to be made because you fully understood at least at a layman's level, how the hash works, what the pros and cons of it are.  At this point, the only reason I'm continuing to elaborate is to hopefully incent you to spend some time researching these things yourself. 

Agreed.

 

1 minute ago, gizmola said:

This is the reality -- if your system is so deeply compromised that all the data and source code and key values and salts you might be employing are known to them, they likely have full control of your entire infrastructure and can just siphon off all of your transaction data in real time or shut your system down, encrypt all your data and hold you hostage.  

Agreed.

But my OP was trying more to CYA as far as protecting the data that I would hash - whatever it may be.  Also, i was asking in terms of PCI compliance.

 

 

[Secure PHP Hash]

9 hours ago, gizmola said:

This is a well articulated explanation of the point I was trying to make earlier about making things overly tough for the paying customers you want (the 99.5%) in order to police and provide barriers for the .5% you don't want.  History has shown that this is a bad business model.  You have to be very careful about alienating the customers you want.

To become a member of my website (i.e. buy a paid subscrption), all I am asking for is a...

1.) A valid email

2.) Valid credit card payment

That describes every e-commerce site on the Internet?!

What is so obtrusive about that?

 

Just to be clear...  If you don't buy a paid subscription, then you cannot have an account.  (My site is not like PHPFreaks.)  All you can do if you are a "Visitor" is read the free articles and some other free content (e.g. podcasts) on my site.  So I am NOT asking anyone to cough up credit card details or other info just to use my site.  But if you want an account, and access to premium content (e.g. premium articles, interviews, podcasts, analysis, ability to PM other members, post comments, take surveys, etc) then you need to buy a subscription.

 

9 hours ago, gizmola said:

If we once again return to the questions you've posed about "security", for your purposes a hash is secure.  You can not take a hash and determine what the input was that created that hash.  md5 and sha1 are often used for fingerprinting of things to determine if they've been tampered with.  A pdf document for example, uses sha1. 

In the bad old days people often used md5 and sha1 to store passwords, and what would happen is that if the system got compromised, perhaps through a sql injection issue, then the entire list of user account password hashes might be disclosed.   In those days crackers would have pre-generated rainbow tables of all sorts of common words phrases and names that people would use in the bad old days.  A quick check against the table for a large membership database, and I might find 10% of the users had bad passwords that matched hashes in a rainbow table.  Those crackers could then, perhaps with an email address in hand, try the same password on other systems, and people being naive as they tend to be, often reuse the same password across systems. 

In more recent times supercomputers and high performance gpu clusters have proven to be able to do incredible numbers of hash calculations per second, so they can attempt to compute enough hash values to find a hash collision.  This is not knowing the original input, but rather crafting some input that computes to the same hash value.  I don't need to know the original password, but I have something just as good, which is a password that will still match.  For this reason, people have stopped using md5 and sha1 as computed password values, and the industry has moved to techniques that are slow to compute.  

None of this is relevant to the use case you prevented [presented] of having a fingerprint value computed from portions of a user's personal information. 

Couldn't a sophisticated hacker use a "Rainbow Table" to reverse engineer my hashed value of say "Cardholder Name" and "Last-4 of CC"??

 

 

9 hours ago, gizmola said:

So if you were to take a bunch of input (name, address, partial cc#) and hash it with sha1 or md5 along with some other input like a "salt" value, and store that in a database, you could use that later to see if some new user info matches a "banned" user.  Yes you could do that.  But can you reasonably expect to ask people for their full address for an online account when they aren't required?

You need a "Billing Address" and that is an address...

 

9 hours ago, gizmola said:

Unless you are shipping me a product, you don't need my address. What you need to get a payment from me is:
-Name on the card

1. -cc#
2. -expiration
3. -ccid
4. -billing zipcode  (usually for a higher level of fraud detection, but likely irrelevant for your online system).

I haven't looked at what configurations Authorize.net has - and of course that has probably changed since I last looked - but maybe two years ago I recall that they had an option where you could require a "Billing Address" for your merchant account.

Also, think about how many e-commerce sites ask for a "Billing Address".  (I cannot think of a time where all they asked for was my "Zip Code".)

Now I could be wrong, but for "Card Not Present" transactions (e.g. online), I thought a full "Billing Address" was required?

Either way, I buy thousands and thousands of dollars of things only each year, and I cannot remember ever NOT having to cough up the following...

- Cardholder Name

- Full Billing Address

- Card Number

- Exp Date

- CVV

- Billing Phone Number

 

As I recall, "Billing Phone Number" was another thing i could configure in my merchant account as a required field, and I have never bought anything online that didn't require that.

So what i am asking for - only for people buying a paid subscription - is the same information 99% of online merchants already ask for.  So where is the issue??

 

 

9 hours ago, gizmola said:

A lot of people are going to balk at giving you address information without an understanding of what you plan to do with it, knowing that you will store that information in your system and not do anything with it which just opens up the possibility that my personal information might be stolen from you at some point in the future.  There's risk, but what is not clear to any of us, is what it is about your system that represents a reward substantial enough to pry information from a significant user base.

Please name some major merchants that you have purchased from ONLINE in the last 2 years that did NOT require a "Billing Address" and a "Billing Phone #"...

This I gotta hear....

 

9 hours ago, gizmola said:

You asked about how and why cc processing uses nonce values.  It's exactly because as you already know, PCI compliance is expensive and out of reach of most businesses.  It is simply a better work around to take input securely and pass that to the cc processor securely, who then issues you back a nonce for the transaction.  The payment processor stores the cc details on their system, but you use the nonce they gave you to proceed with the rest of the payment process you need to eventually get a transfer of funds from the credit card issuing bank to your bank.  In the US, given the way laws work that usually doesn't happen for 30 days anyways.  You are not storing any personal cc info, and they don't want you to.

Correct, but I do not believe it breaks PCI compliance if you store "Cardholder Name", "Billing Address" and "Billing Telephone #" does it?

 

9 hours ago, gizmola said:

In order to establish any recurring payment, you have to use a feature the payment processor provides to you where again, you will not store the cc# but they will on your behalf.

And that is what I was calling earlier, a "Payment Token".

I believe that all that is is a hashed value that the merchant is allowed to store in plain-site, and which (supposedly) cannot be reverse-engineered, BUT when you provide it back to your payment gateway, the processor WILL be able to use that again to successfully charge the customer again.  (Would probably break with a "virtual" card number, though.)

 

9 hours ago, gizmola said:

Needless to say a lot of things can go wrong with recurring payments -- the card could be cancelled, it could lack funds at processing time, etc. etc.  Lots of people are pretty savvy these days and have had bad experiences with services that they can't unsubscribe from, so again you better have something people really really want badly in order to sign up for a subscription.

Ironically, I am not offering recurring billing - which most sales/marketing people would shoot me for.

One, I am not offering this, because I don't have the time to learn how to do it - and maybe I'm not smart enough to figure it out?!

Second, I am confident in my my offering, and when someone's annual subscription is about to expire, I will send a reminder email, and IF I have done my job, then they will MANUALLY buy another subscription.  if not, then I lose a customer.

No high-pressure sales, no "locked in" contracts.  Easy-peasy.  (Just don't screw around and break my TOS, or you donate your subscription $$$ to my piggy bank!!)

 

 

9 hours ago, gizmola said:

You could siphon off a portion of the cc# and store the last 4 digits, but I don't find that substantially more useful than the input you are already going to ask for, and at the end of the day it's a half measure that I can predict might catch a couple of people at most, and do nothing to deter anyone determined to get around this check, so at best it can only be one of many.  

As stated above, I am thinking "Cardholder Name" (already vetted) and "Billing Address" or part of it (already vetted) and "Billing Tele #" is a powerful combination for most cases.

Another thing I am considering doing, although this could easily become a full-time job, is to do a quick "order verification" by phone.

Again, this is VERY common in my own experience buying things online.

So whether you are the Russian syndicate or a lone identity-thief, unless you do great voice impersonations, how are you gonna fool me even if you have 10 active credit cards at your disposal?

 

Definitely a good conversation, and thanks for the advice from everyone - albeit a little "harsh' at times!! 

[Secure PHP Hash]

9 hours ago, kicken said:

Now if you want to require payment and think your content is good enough people will pay for it then fine.

Right.  I do.

 

9 hours ago, kicken said:

Storing the name and last 4 in plain text would be fine by PCI standards as far as I understand, no need to even hash it. 

Actually I recall that storing the Last-4 is okay now that you mention it.  Guess I need to read the latest laws and regulations.

 

9 hours ago, kicken said:

And here's the crux of why your idea is DOA and not worth even doing.  How does it stop what you just said you want to stop?  If they are coming back with new card numbers then what good is comparing the old one going to do?

Not accounting for stolen identities and credit cards - which is a whole other category - I would think that "Cardholder Name" (usually a Legal Name since it is vetted much better through a bank), "Billing Address" (again, already vetted for me through a bank) and a "Credit card Number" is a pretty effective way to identify MOST people.

Even if Requinix used his "virtual" card numbers, the "Cardholder Name" and "Billing Address" would be the same.  (And for people like me that have more than one  "Billing Address", you still have a finite universe, plus likely the same Zipcode and so on.

I've spent a lot of time working for banks as my client, including the last 3 years at a major bank in the credit card division, so don't tell me that institutions aren't checking up on customers.  Now, obviously I'm not a bank, but just like your gym or daycare center or doctor's office or church or cable company or storage facility or golf course, I have a right as a merchant to have enough information about you to make sure I get paid AND to protect my company, my employees, my assets, and other customers.

I am not asking for DNA samples, but I am hoping that having a "Cardholder Name", "Billing Address" and "Billing Phone Number" is enough to keep track of MOST people, and to act as enough of a deterrent that jerks and trolls stay away.

And all I was asking about in my OP, was whether it was secure to store any of the info above - minus obviously card details - using a secure hash or whatever else PHp might offer.

 

9 hours ago, kicken said:

This is all you need.  The sheer fact that you require payment is deterrent enough.  Your average troll isn't going to spend money over and over again to keep posting.

I would hope that would be enough.

 

9 hours ago, kicken said:

Even if they do, then so what? Take that extra money you earn and use it to develop a solution that actually works like paid moderators, better content filtering, etc.

Well, according to my TOS, I can take your money if you get kicked off of my site because you broke the TOS.

Again, though, all I was asking in my OP is how to store some of the info I mentioned, or determine if it would be too complicated - as it would be if you wanted to store credit card details.

 

9 hours ago, kicken said:

You need to consider the real world, not your little fantasy world where people will just re-used the same card, get denied and say "Well darn, they got me!" 

Most trouble makers will simply be stopped by the fact they have to pay.  Once you ban them they will be gone and not try to come back.

Okay.

 

9 hours ago, kicken said:

The trouble makers who are not bothered by the payment will have no trouble defeating your little card check.  Most likely they won't care because it won't be their money, they will be using a list of stolen credit cards and they will just move on to the next card in the list.

So how would you stop people like that?

 

9 hours ago, kicken said:

For those who actually are using their own money, they will just sign up for some virtual card number service (if they don't already have one)

But they will have the same "Cardholder Name", "Billing Address", "Billing Telephone Number" and "Billing Zip Code", right?

 

9 hours ago, kicken said:

So the end result is that the only people you'll stop are those who genuinely want to join your community and want to help their friends/family join also by offering to pay their subscription cost for them.

Earlier I stated that I was going to allow 2 accounts per cardholder.  (I might be willing to allow 3.)

That would allow someone to buy a subscription for a spouse, bf/gf, child, or friend.

I just don't want one cardholder having 20-30 accounts linked to their credit card, because then I suspect there is something fishy going on.

 

9 hours ago, kicken said:

They won't be able to due to your stupid little check for duplicate cards.  Maybe they will be smart/motivated enough to get a virtual card number and work around the problem, but most likely they will just get turned off to the whole idea and at best, won't buy a sub for their friend or at worst will cancel their sub and stop using the site all together.

They can buy a gift certificate...

 

9 hours ago, kicken said:

So how do you accomplish your utopia that you want to create?

1. Require a payment to join that's low enough to not deter a sign up, but high enough to deter repeated signups.

I have that.

 

9 hours ago, kicken said:

1. Higher Hire people (or convince your community) to moderate the site and take down and ban spam/troll accounts quickly.

if things become successful enough, maybe I can do that.

 

9 hours ago, kicken said:

1. Invest in technology that helps with #2 like easy to use tools and advanced (AI driven?) filtering to catch problem accounts early/quickly

I already have built in ways for other paid members to flag PM's, flag Profiles, and flag Posts.

And in version 2, I hope to have time to build out an idea I had 5 years ago which is a "Reputation Score" which I can further use to reward/punish people.

 

9 hours ago, kicken said:

Nothing will be perfect, but your current plan isn't even viable.

Still feel that way after my responses above?

 

[Secure PHP Hash]

6 minutes ago, StevenOliver said:

PHPFreaks DID have a data breach! (https://www.cyberinsurance.com/breaches/phpfreaks/)

Thanks for the link!!  (I'm not sure if I knew about this, or if I did know, I forgot, because there is nothing for me to lose here.

 

6 minutes ago, StevenOliver said:

I had an afterthought.... if I absolutely HAD to store some encrypted customer data, I would lean towards storing their phone number over storing their credit card details. And it would be easy to assign a random "code" via a text message. Nowadays a lot of sites that "want to prove it's really you" will send you a text message with a 6 digit code. You could probably still do a good job at enforcing your 2 people per card limit this way, without having to store (or even see) their card info. Their phone number should still be encrypted properly, though, but it looks less catastrophic if phone numbers got revealed rather than credit card numbers 🙂

Yes, I think there are other pieces of info I could use to verify that a person is registering and maintain my 2 accounts/card limit.

Then again, the laws are changing (e.g. California Privacy Act, and GDPR), and like most laws, things are left to interpretation by the courts.

I am also considering calling people after the buy a subscription and having a quick conversation asking them some details, maybe set up some "challenge questions/answers", and basically letting them know that they should consider their membership/subscription to be like they joined some group in real life (i.e. absolutely no bullshit).

Of course, I won't count on Requinix joining anytime soon...  😄

And to @gizmola's point, there is something to be said for focusing first on getting a following, and next some sales, and then maybe stepping up background checks as needed.

 

[Secure PHP Hash]

5 minutes ago, StevenOliver said:

SaranacLake, even though I am probably the worst PHP person on this whole forum, I was fascinated with encryption and hashes, and a few months ago, I spent almost a full month studying PHP encryption! I don't need it for my own site, I just studied it for the same reason I read this forum -- it is fascinating! I learned how to do lots and lots of encryption, very secure encryption, but I also learned that with ONE little mistake, one slip of the code, ONE server misconfiguration, and you might open yourself up to some big lawsuit

Yes, that is true.

 

5 minutes ago, StevenOliver said:

(Look at all the big multibazillion dollar companies that have been IN THE NEWS for their stupid data breaches! And they TEAMS of encryption geniuses, working for them, and they STILL couldn't get it right.

Well, I have spent my career working for "multibazillion dollar companies", and first of all I can tell you that "looks can be deceiving"...

Most of my clients have been run by idiots, regardless of whether or not they made truckloads of money.

Yeah, sometimes a nation-state penetrates a large American corporation, but usually it is freshman errors that brings companies down.

 

5 minutes ago, StevenOliver said:

But in my opinion, just my opinion, it would be better to hire a reputable first rate security company to do the credit card portion of the code you require. Then, if worse came to worse, and for whatever reason you had a data breach, you won't be in the awkward position of having to say, "well, I proudly did all the security coding myself, all the forums said my algorithm was secure..." 🙂

Again, just my opinion.

And a valid point, but my counter would, "If you are afraid that something might blow up with your code, then you best not be a programmer.  There are a million places where things could go wrong, and if you never wanted any risk then you'd never be able to do anything in application development.

PHPFreaks could have a data breach and get sued also, but that doesn't stop the owner from running this forum.

Also, in my case, like most proper checkouts, the data is going directly from a secured webform to my payment gateway, so that's a lot easier to do than, say, storing credit card details in your database.

My hash idea is certainly more risky, but it never hurts to investigate things.

Thanks.

 

[Secure PHP Hash]

3 minutes ago, StevenOliver said:

If I were in your shoes, and were going to proceed, no matter what, in spite of this thread's recommendations against it, I would DEFINITELY 1.) Hire a licensed bonded and insured security firm to do the "limit 2 people per card," coding you require, and 2.) have a darn good liability insurance policy for yourself that covers data breaches!

So you make it sound like using a hash is not nearly as infallible as was said above, right?

I'm guessing that using the "security token"  that most payment gateways offer is probably the safer way...

 

[Secure PHP Hash]

5 minutes ago, gizmola said:

Given your comments, I understand your concern.

Tell @requinix that - he now thinks I'm part of the "Deep State" - or is that the "Red State"?!  *LOL*

 

5 minutes ago, gizmola said:

If you get to the point where your community is successful enough to have the issues you describe then you can pay people (or in some cases entice them to moderate for free) your community.  This is how this forum works.

I understand, but you realize that free forums usually end up closing because it becomes a full-time job to clean up troll posts and it becomes unmanageable.

The reason this happens is because there are no incentives online to behave.  No consequences anymore.

But $$$ is king!!  

If people realize they will lose $60 and be blocked for good, they will likely have second thoughts about subscribing if their only goal is to incite riots, or they will think twice before they post.

Maybe I was naive in thinking I could rely on Cardholder Name, Billing Address, and Payment Details as a way to uniquely identify people.

It may not be foolproof, but I still suspect it would eliminate most of the issues.  (I'm sure Requinix completely disagrees with me!)

 

 

5 minutes ago, gizmola said:

The forum software does have tools that will blacklist emails and ip's, but neither of those are fool proof. 

Right, because of free emails and VPNs.

 

5 minutes ago, gizmola said:

They still make it an annoyance for anyone who has not automated signups.  The average crackpot will simply move on.

You think American (or Russian) trolls give up that easy?

 

5 minutes ago, gizmola said:

The other thing that we face like most sites with any significant user base, is attempts to spam or advertise.

Aha, but that is in my TOS.

Willing to pay $60 for a one time spam message that gets you blocked and the message gets deleted?

I'll take the donation!  😉

 

5 minutes ago, gizmola said:

Again our small volunteer moderation group, along with the forum's ability for people to report posts they think violate our rules insures that we have almost no spam or abuse presence on the forum lasting for any significant amount of time.  More often than not, if I see a report, it has already been handled by one of the other volunteers.

It's good that your small army is winning.

 

I just see what happens on sites like Facebook, Twitter and Reddit and I figure that I need more than that - not that I am that successful (yet)!

 

5 minutes ago, gizmola said:

Again, having too many users with some that won't follow the rules is a good problem to have.  I simply happen to believe strongly that it's more important to concentrate on your MVP, and building your traffic and user base than it is to try and engineer a solution to a problem you don't yet have, when you haven't implemented the tried and true, if imperfect, controls that other sites utilize first.

Okay, that may be the wisest thing spoken yet in this thread, and I will concur with you on that.

At the same time, now is indeed a good time to make architectural decisions before the cement hardens!!

 

That being said, could I use a hash securely if it is based off of thinks like Cardholder Name, Billing Address (or part of it), and possibly Last-4 of credit card?  or is that a train-wreck waiting to happen?

 

Also, does anyone here have experience with 'payment tokens" which I believe do the same thing, but which are considered PCI complient?

 

 

 

 

[Secure PHP Hash]

19 minutes ago, gizmola said:

Just to go back to the original question, I'm not sure you are clear on what a hash actually is.  A hash takes input and computes the hash.  Hashes are not encryption with associated decryption.  You can not decrypt a hash.

But I don;t want to decrypt anything.

For instance, let's say that "Linda Zeiger" from "123 Main Street" subscribes with a "Visa" ending in "1234" and I create a hash.

Then if Linda got kicked off of my site for breaking the TOS - and after being given a couple of warnings to get in line - then if she came back and tried to create a new account using a new email address, but the same "Linda Zeiger" from "123 Main Street" subscribes with a "Visa" ending in "1234", then i could compare that hash to the stored hash, and determine if I let the registration go through.

Same way logging in works.

Now obviously there are lots of ways to get around that, but to your concern, using a hash would work.

And to my question in my OP, is doing that secure?

I'm guessing it is not allowable by PCI standards, but you never know...

 

19 minutes ago, gizmola said:

They are also not part of php per se, but like most languages well known hash algorithms are available in php.  Assuming you had a good use case for a hash, then md5 and sha1 are popular options.  The more unique input you provide to the hash, the better it tends to be.

SHA1 is super hackable, is it not?

Last I heard, SHA-256 (?) was a better choice, but maybe that is easy to reverse-engineer, and get this from t...

"Linda Zeiger" from "123 Main Street" subscribes with a "Visa" ending in "1234"

 

[Secure PHP Hash]

20 minutes ago, requinix said:

Oh great, so it's an exclusive community. And I have to pay to get access to it. I'm sure the 1% will love it.

Lots of undertones there...

 

20 minutes ago, requinix said:

There it is.

And again.

 

20 minutes ago, requinix said:

But we're not talking about screwing around. You want to target "anonymous users that do not behave the same way they would in real life". Your goal is to make sure that you have a community full of nice people who have to be careful about what they say lest they offend someone.

Did you get excluded from some club earlier in life and you're bitter?  *LOL*

The only thing you can do on my website for free is read free content.  Period.

With a paid subscription, you get a lot more.

Don't want a lot more?  Then don't buy a subscription.

Nothing "elite" here.

But IF you buy a subscription, and I give you the ability to talk with others and post comments, then you have to follow the TOS.

If you don't, then you're gone.

And I'm just trying to make it difficult for the same people to come back again and again and slip through, because you know they are only coming back to get revenge.

That's the problem online....  People feel everything should be free and they should be able to behave however they want.  I disagree.

I challenge you to buy a subscription to the NY Times, WP, or Wall Street Journal and become abusive on their websites and see what happens...

 

20 minutes ago, requinix said:

Do you think PHP Freaks should require proof of identity for all of its members? After all, it's only to "protect our online community".

You are twisting what I am doing.

The only info I ask for is e-mail address, password, and payment details - which includes name and billing address.

 

20 minutes ago, requinix said:

You do the same thing every other online community does: ban the user, keep an eye out for their IP address and familiar activity from other accounts, and move on with your life.

But how effect - alone - is that?

 

20 minutes ago, requinix said:

I'm done. I have other things to do than fight this. Like I said, I can't stop this from happening, but I'll be damned if I help it along.

You're fighting with some shadow here.

I asked for clarification on a technical matter, and now you are all mad at me because you don't like the approach i am taking - which is the same approach pretty much every other online paid subscription takes.

 

[Secure PHP Hash]

19 minutes ago, gizmola said:

Yes this idea is DOA.  First of all, people are loathe in the modern era to provide identifying information.  The less information you require to establish an account the better, if you want people to sign up.  People provide information when they have an incentive to do so.  A "community" where people won't join because it's too much of an annoyance to join will be a ghost town.

People have to provide a Cardholder Name, Billing Address, and Payment Details just like every e-commerce site since the beginning of time.

If you don;t want to provide that, then you cannot buy a subscription.

Where did i say i was asking for anything else - other than email address?

 

Quote

In my experience it's hard enough to get people to pay for a service, even a well executed one that people use everyday.  Before stackoverflow, there was experts exchange.  It was once a thriving tech expertise community, then they tried to monetize it by obfuscating the content unless you paid.  This really pissed a lot of people off, and the site went rapidly down hill until it eventually went bankrupt.  SO was started partially in response to EE's poorly executed paywalling scheme, and the rest as they say is history.

Let's talk about my use-case...

I am building a website that is part online newspaper and part community.  There will be lots of free content, but for premium content, you have to pay.  And as a paid member, you also get to join the online community and create a profile, chat with others, post comments, and get access to much more.

This is not a new concept, and it works IF you have phenomenal content.

If you don't have a paid Washington Post subscription, you cannot post on their site.  And while they might not kick you off their site if you posted nasty messages, I guarantee you'd be blocked from posting again.  (And if you came back pretending to be someone else, I'm sure they could catch you.)

Don't like that?  They be try CNN or Fox News which are free.

Why is what i am trying to do (i.e. paid subscription) so radical?

 

Quote

Candidly I have been asked many times over the years to come up with ways to prevent people from getting access to a system or to content.  This goes back to days I worked in the gaming and entertainment industry.  There are some interesting case studies as to the effects of over emphasizing piracy or restricting access to content they have paid for, and in every case the employ of those technologies harmed or hampered the business over time.  Meanwhile competitors that wrote off the concern thrived and often overtook competitors that at one time were the market leaders with a huge competitive advantage.  The harder you make things for your users/customers, the worse off the business will be over time.

But I'm not making things "hard".

All I am trying to do is enforce the TOS.

No one is forcing people to buy a subscription.

But if you do, I do expect people to behave - otherwise i end up with a cesspool like social meda...

 

P.S.  I appreciate your feedback, but I don't think I'm being unreasonable here.

 

[Secure PHP Hash]

3 minutes ago, requinix said:

They are the "bank" for a block of credit card numbers. When a transaction needs to be processed it goes to their system and they can handle the charge however they want.

I just read an article about them.  Not sure I see any real value.  if your credit card get compromised, get a new #.

(If you have to sign up for that service - especially with a 3rd party - you are probably defeating the purposes by having to cough up even more details that can be breached.  That and the article I read mentioned using a browser add-on which i wouldn't touch with a 100 foot ppole!)

 

3 minutes ago, requinix said:

lol

Why is that so funny?

 

3 minutes ago, requinix said:

Riddle me this:

Why the hell would I want to sign up for your community knowing (a) you are taking my personal information, including credit card numbers, in such a way that you are actively trying to establish my identity, (b) are doing so for reasons that have nothing to do with me initiating transactions on your site, but instead (c) are doing so because you want to be able to terminate my account if you decide that you don't like my behavior?

Because every company in the world that sells memberships does this.

What does your gym do?

You gun club?

AAA?

How about the NY Times or Washington Post?

You are paying to join my online community - which is a feature of buying an annual subscription - and if people cause trouble then i want the ability to block them, and not have Russian trolls coming back every 20 minutes with a new email and credit card number.

 

3 minutes ago, requinix said:

Have you learned nothing from Twitter or Facebook or YouTube? Or from what is happening in China?

What does that mean?

You mean "Big Brother" watching you?

If so, the difference is that I am not selling your info like Zuckerberg, and I'm not going to come to your home and beat your family if you mess around.

I would like a reasonably reliable way to keep riff-raff out.

 

3 minutes ago, requinix said:

I can't stop you from going forward with this idea, but I can tell you that I hate it and would never sign up for it.

Nothing personal, but don't be so sanctimonious about online memberships.

I challenge you to get an in person "membership" to any club (Elks Club, golf course, hunting club, tennis club, gym membership, etc)  where there are no reprocussions if you screw around.

How about  even a store or restaurant?

Of course in those cases, they can see who you are.

So why is it so offensive to you that I am trying to protect my online community that is member's only?  (Not the same thing as on online PHP forum...)

 

Either way, so what other things could I do to establish someone's identity - and let's not make it sound like I am China - so if they break the TOS then I would have a way to refuse them service in the future?  (Or to the point of this thread, if their 50 friends use their credit card and THEY screw around, then I need a way to take action.)

 

[Secure PHP Hash]

4 minutes ago, requinix said:

I have on my phone an app that lets me create nearly unlimited valid credit card numbers associated to me. I can defeat your system by taking the same measures I would with every other online transaction I enter into: by creating a new virtual card.

So how does that work?

I have never heard of virtual credit card numbers before?!

 

4 minutes ago, requinix said:

That's to say nothing about the fact that I have more than one billable piece of plastic to my name.

Most Americans have several credit cards.

 

4 minutes ago, requinix said:

Trying to say that a credit card is an identity is naive.

But it is a start.  Do you have a better idea?  I could make people meet me in person in a parking lot with their gov't issues id...  😉

 

4 minutes ago, requinix said:

Why do you care whether someone uses the same credit card? I pay Netflix for myself and two other people, using three separate accounts, all with the same billing information. Do you think they care?

Because I am creating an online forum, and I want people to have some accountability.

One of the reasons the Internet sucks so much in 2020 is that most online sites and forums and communities are filled with anonymous users that do not behave the same way they would in real life/

The problem I am trying to solve for - and it sounds like you are giving me an "F" once again - is a way to make sure people have "skin in the game".

So my (naive) plan was that if someone creates an account and pays with a credit card, and then they break the TOS, not only do I kick them off of my site, but if they try to create another account using the same details I have a *reasonable* way to stop them.

Now in that design, I know someone could have another credit card with different billing details - I know I do - and of course, nothing is stopping them from using someone else's credit card, but the goal is to create a reasonable deterrent and a way to keep people more accountable.

So since my idea sounds like it it is DOA from the get-go, what better ideas do you have?

(Note: I'm not issuing security clearances, but i don't want to have to deal with dicks/trolls/punks/etc...)

 

[Secure PHP Hash]

Just now, gw1500se said:

Then you are using a database (MySQL) to store the data? When you store the data, encrypt it.

I am not storing the payment details.  Those would go from my checkout form *directly* to the payment processor.

You would need PCI compliance and wicked infrastructure to be storing payment details!!

But I was wondering - probably naively - if you securely hashed just part of the details - enough to uniquely identify a cardholder and the form of payment - if you could then retain that safely and not have to worry about a data breach and getting sued.

I'm pretty sure there is the concept of a "payment token" that does this, and it is used for cases where you have things like recurrent billing (e.g. for subscriptions), but I am not familiar how to do that, and as I recall, the documentation from Authorize.net leaves a lot to be desired.

[Secure PHP Hash]

1 minute ago, gw1500se said:

Define "capture." Are you talking about a way to store the info or to obtain it from a web page?

> So if Lisa Smith buys a subscription, I want a *SECURE* way to maybe capture her name/last-4 of credit card/exp date

> and store it so that each time a new person registers, I can make sure the 2 members/credit card is not succeeded.

 

I am looking for a way to safely store the Cardholder Name + Last-4 of credit card + Exp date (or something like that) so that I can keep track of how many times a credit card is used with respect to new accounts.

The payment details are really the only way I have to link a subscription to a human being, short of calling everyone or something like that.

Does that answer your question?

[Secure PHP Hash]

3 minutes ago, gw1500se said:

The regular PHP hash is a one way encryption. I cannot be decrypted except via brute force.

So here is a problem that I am trying to solve, and security is of the utmost importance...

I am building a website with subscriptions, and my business rule says that there cannot be more than 2 members per credit card.

My reasoning is that I want to use the credit card payment not only to get $$$, but as a means of connecting a real human being to an user account.

If I allow 50 member accounts for one credit card, then it defeats the point.  (The assumption is that allowing up to 2 member accounts per credit card payment allows for things like spouses or parent-child.)

And, yes, there is always a way to "hack" the system, but I think this approach is sufficient for now.

So if Lisa Smith buys a subscription, I want a *SECURE* way to maybe capture her name/last-4 of credit card/exp date and store it so that each time a new person registers, I can make sure the 2 members/credit card is not succeeded.

Is there any reasonable way that I could do that using a hash, or is that suicide/

(BTW, I will be using Authorize.net for my payment gateway, and maybe they already offer a way to do what i want, but since I am not at the point to where i am setting up the payment gateway to my website, I am trying to think of ways to accomplish what I need just using PHP.)

 

[Secure PHP Hash]

Are there any PHP hashes that are extremely secure and that CANNOT be reverse-engineered?

 

 

[Handling Subscription Dates]

11 hours ago, requinix said:

I think you missed the point. It doesn't matter what timezone the user is in because you're recording and comparing dates on the server. A duration of one year is a duration of one year for everyone.

Right, that is the same conclusion that I came to!  😉

 

 

11 hours ago, requinix said:

Please localize it.

So I would store everything in my database as my local time of EST, and then use PHP to localize the dates in the user's control panel?

 

 

11 hours ago, requinix said:

Don't record the end time at all. It starts at a particular moment, it goes up until the date that's one year later, and you check for validity using a <= so that the end date is also considered valid. It will give the user slightly more than one year, and depending on timezones that extra may or may not be noticeable to the user, but who cares.

A few things here...

1.) So it sounds like you are saying that I should use a DATE and TIME and record the moment they make a purchase as the 'start date", right?  (I guess I could use a MySQl "TIMESTAMP" datatype for that?)

 

2.) My database design has a "start_date' and an 'end_date" for a subscription - otherwise how would I know when a user's subscription had ended?

So I think what you are saying is on registration/renewal to grab the TIMESTAMP and stick that in the "start_date" and then maybe use a date function in PHP or MySQL to add 1 year onto that 'start_date" to calculate my 'end_date" - which would need to be written into my "Member_Subscription_History" table.  

Is that what you were suggesting?