Secure PHP Hash

[kicken]

Not gonna like, this was TL;DR after a few posts and sounds just like previous threads where we tell you something is a bad idea/wont work and you just push back.  However, I'll reply anyway.

6 hours ago, SaranacLake said:

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?

None of those places try to turn a credit card into an identity like you are trying to do.  They use the card for what it is, a payment method.  Any place that is actually interested in a persons identity will require a government issued ID.

5 hours ago, SaranacLake said:

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

Your asking for a persons billing details.  Whether you store that or not isn't that relevant, just asking for it will deter a ton of people from even considering signing up for your site.  That is simply too much personal info.  Now if you want to require payment and think your content is good enough people will pay for it then fine.  Don't think that because your not storing that payment data that people won't care that your asking for it.  They will, and many will consider it a deal breaker.

5 hours ago, SaranacLake said:

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

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. 

6 hours ago, SaranacLake said:

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.

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?

5 hours ago, SaranacLake said:

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.

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.  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.

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.

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.  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)

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.  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.

 

 

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.
2. Higher people (or convince your community) to moderate the site and take down and ban spam/troll accounts quickly.
3. Invest in technology that helps with #2 like easy to use tools and advanced (AI driven?) filtering to catch problem accounts early/quickly

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

 

[gizmola]

6 minutes 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.  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.

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.

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 of having a fingerprint value computed from portions of a user's personal information. 

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?  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).

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.

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.  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.  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.

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.  

 

 

 

 

[SaranacLake]

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?

 

[kicken]

24 minutes ago, SaranacLake said:

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.

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

Quote

Reasons why you might want to use unique card numbers

People use unique card numbers for many reasons. Many of them value their privacy and the fact that you can spend pseudonymously (using a fictitious billing name and address). Some enjoy the added control it provides over their spending. Others enjoy the fact that you can prevent merchants from rebilling you automatically for subscription purchases.

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

 

5 minutes ago, SaranacLake said:

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

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.

 

15 minutes ago, SaranacLake said:

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.

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

 

6 minutes ago, SaranacLake said:

Still feel that way after my responses above?

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.

[SaranacLake]

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!! 

[StevenOliver]

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." 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).
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.")
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).
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!).

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.

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.

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!!!

 

 

 

 

 

Edited April 26, 2020 by StevenOliver

[gizmola]

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?  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

 

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.  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#.

Quote

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

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).  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. 

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.  

[SaranacLake]

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.

 

 

[SaranacLake]

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!!

 

[SaranacLake]

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!!

 

[gizmola]

This thread has already gotten really long winded so I'll try and conclude with some final cherry picked replies:
 

PCI Compliance

If you have a server in the cloud you simply can't be PCI compliant.  You aren't really allowed to handle credit card data yourself -- but instead utilize the payment processor.  This essentially reduces your concerns at the PCI Level 4 merchant level (or below) to doing a self assessment document.  All you get from a payment processor, and will be allowed to store and use subsequently is tokens. Tokens aren't hashes either -- but are instead single use (nonce) keys that let you interact with the payment processor.  At any point along the way if you are storing the original credit card input, you are at risk of running afoul of pci dss which you don't want.   You can't store the cc info, even temporarily in a session variable to make the form process work nicely.  This is one of the reasons that just about every modern payment process has a final step where the payment information is dealt with separately, and why the cc info is not retained between calls to the gateway.  

You wrote about how you would do subscriptions without doing subscriptions, which basically means that you will have to start messaging people about their pending renewal, and when it gets around that time, you will need to do a new transaction where they enter all their payment info again as if it was the first time.  You kind of positioned this as a badge of honor, but it's a really poor decision for a subscription reliant business.  I literally have never seen a single subscription business that involves that design.

The hash in support of the ban tool

You could go ahead and do what we've discussed, and take a piece of the cc# along with other pieces of name and address and make a hash and store it.  You could also check against your own table of fraudulent credit cards and intercept a potential transaction before its sent to the gateway for that matter.  You just can't store any of the inputs being provided to you persistently.  

Is a hash based on a piece of a cc# useful?

Numerous people have pointed out the same issue, which is that people can have lots of different cc and cc#'s.  The thing that Requinix described is not some esoteric product, but offered by large banks like Citibank, Capital One and Apple (backed by Goldman Sacks) to name just a few.  It lets a customer go in and generate a disposable card#, ccid and expiration to be used for one or more transactions online.  It's existence entirely defeats your hash.  In fact it suggests that adding in any part of a cc# makes the hash less effective.

Given these facts, assume you go ahead with your original idea.  How will you create this table of "bad hashes" in the 1st place?  Are you going to make a hash for every paid user stored with a flag that is 'ok' and then flip that to 'banned' or something like that?  If that's the case then you would have with sha1 for example, to store a 40 character string in your database for every single user, just so that you can flip that on a handful of users at some future time.  That's a lot of storage for something that would be used infrequently.

Is a billing address required for ecommerce?

I can only answer this technically having implemented e commerce numerous times with different vendors.  With some of the largest payment processors in the marketplace, the address is not part of the input to the gateway.  You may do with that what you will, but again, if I'm not shipping you anything then what do I need your address for?  I brought up the gas station example, and your reply was that the card was present.  That is true, but why then are they asking for the zipcode?  It is because the card could have been lost or stolen.  It's just an additional check.  With ecommerce, the entry of the ccid is the equivalent mechanic that validates the card is present.  You should also know that credit card fraud is *your problem*.  Most of the payment processors offer their own fraud prevention services that you can pay for or not.  There is no built in visa/mastercard/amex/discover fraud prevention system you just get automagically.  Fraud = chargebacks, and chargebacks are bad for your business and will cause your per transaction costs to go up, or can even lose you your merchant account.  

Payment tech is changing

Younger people are using mobile payment tech like apple pay, google pay, samsung pay etc.  There is also a long tradition of alternative payment options, with the most prevalent being Paypal.  Most people that take payments are going to support paypal, and you might also like to support these newer technologies at some point, and none of them have credit card #'s.

Legalities

There is a lot of state and federal consumer law out there.  Just because you put something in a TOS that takes away someone's rights doesn't mean that will stand up in court.  

My final word

If you want to do what you originally brought up, then technically it can be done.  Requinix wouldn't if it was his company, and I wouldn't if it was mine.  I just don't think it would be worth the time, effort, and storage cost, even though it could be coded up relatively quickly by someone who understood all the parts and technologies well.

Furthermore, if I wasn't stuck in my house right now, I doubt seriously I would have continued to engage in this conversation given the mysterious nature of your proposed business.  I don't want nor need to know what it's about, but I just have my doubts that there is any online community that people will pay for, when there are numerous well established online communities out there that are free.  Usually the devil is in the details for any online business, and it's just not very fun or interesting to tech people to try and guess about what feature might help you enforce rules, without understanding the game afoot.  Get your MVP up and running and then if you want, you can come back armed with specifics and actual real customers, and you'll find people a lot more enthused about your ideas, whether they be viable or not.