Safely Hashing Data

[SaranacLake]

@Zane,

Thank you for the information!!  👍

Over the next couple of weeks, I hope to get my checkout process coded.  As I get closer to the part where I submit the payment to Authorize.net, then I will have to actually learn what all Authorize.net offers to me as a merchant, including what you are talking about.

So if I implemented what you described, would that basically remove most risk that I would have with needing to know who my customers are but not wanting to store their credit card details?

And how hard do you think it would be to code in PHP what I described?  I have never worked with an API - is it as simple as just passing data back and forth to Authorize.net?

 

 

[Zane]

The would remove any risk unless both your database and Authorize.net's database were breached.

17 minutes ago, SaranacLake said:

is it as simple as just passing data back and forth to Authorize.net?

Fundamentally, yes.  It's that easy.  How you go about it though is up to you.  Authorize.net provides sample PHP scripts for sending and receiving the data.  It may look intimidating, but you're essentially just creating a JSON object and sending it to Authorize.net, from which you'll receive a response.

In your own database, all you'd need is your usual fields, and then you could add come columns that link it with Authorize.net's customer profile.

So, there's you typical user table

• user_id
• user_name
• user_pass

You could then add a column for the customer profile id that's generated from Authorize.net

• user_id
• user_name
• user_pass
• user_authorize_id

As for the payment profile, you'd store them in their own table, called say... payment_profiles.  It would contain

• profile_id
• profile_authorize_id
• user_id

Some people roll their own form of sending data, some people use the official code provided
https://github.com/AuthorizeNet/sample-code-php/blob/master/CustomerProfiles/get-customer-profile.php

This way, you don't have to hash anything or maintain anything PII related.  You'll be able to login to Authorize.net as well and create reports of your customers with  Customer Information Manager.  

** This is all assuming that you're only using Authorize.net to handle your transactions.  If you have other merchants, like Paypal, then you'll need to check out what they have to offer as well.

[SaranacLake]

@Zane,

 

Sounds like you have hands-on experience using Authorize.net, huh?

How do you think they compare to other payment processors as far as programming APIs?

And how secure do you think they are in this day and age of perpetual data breaches?

 

[Zane]

It's been over 10 years since I messed with Authorize.net API.  I first used it to allow people to make single secure payments from a web page of mine to a bank account.  That's it.  Back then, they didn't have all of this fancy new stuff.  Therefore, i really don't have any valuable comparisons to give.

Also, I do not consider myself to be anything close to an expert (or even intermediate) level of creating secure systems.  I ran a mail server about 6 years ago and that was a total nightmare.  Literally, as soon as the server went live, it was plagued with bots and whatever else that started using my SMTP server as an open relay and my IP became blacklisted pretty quickly for spam.  I google ad nauseum for how to secure this and how to secure that and what the best practices were, but I was in way over my head with absolutely no budget for anything to help me out.  After 4 years of trying to maintain a mail server that successfully sent and received mail with no issues (though, there were still issues), I finally was able to convince my boss to switch to a Google Business account and let them handle all of that guff.

Mail servers are an absolute nightmare that I wouldn't wish upon my worst enemy.  I mean, installing SSL certificates is easier than maintaining a mail server.  Anyway, this topic has nothing to do with mail servers.

34 minutes ago, SaranacLake said:

how secure do you think they are in this day and age of perpetual data breaches

You know, I've never tried to even perform a breach in my life.  I've never even tried to breach myself.  It's an exhausting realm of web development that I avoid like the plague.  Really, what is secure?  Unless you're a Fortune 1000 company or something, I doubt you're going to have a hoard of people trying to hack your site; don't flatter yourself.  I was a web developer and ran probably the least secure site, in my opinion, but the audience for that site was so minuscule compared to that of large corporations.  It's about the same concept as viruses.  Most people running a *nix system do not really need to worry about viruses because *nix systems do not take up much of the market share for personal computers.  However, Windows is always being probed and poked and molested because it has a gigantic user-base.

In any case, Authorize.net seems to have improved pretty much everything they had when I messed with it over a decade ago.  Most, if not everything, of what I utilized is gone or deprecated.  I mean, I would trust it.

At the end of the day, though, the most secure you'll ever be able to make your system is if you cut it off from the net.  If it's not on the internet, you really have nothing to worry about.  If you're not connected to the internet, you're not going to get any viruses anytime soon.   I know that's not an answer, but it's a hard truth to accept.  Online banking is really awesome in my opinion, but I know that at any particular time, something could go awry and cause my life hell.

 

[SaranacLake]

Thanks for the rants and thoughts!  😉

 

22 minutes ago, Zane said:

It's been over 10 years since I messed with Authorize.net API.  I first used it to allow people to make single secure payments from a web page of mine to a bank account.  That's it.  Back then, they didn't have all of this fancy new stuff.  Therefore, i really don't have any valuable comparisons to give.

Ironically I got an Auhorze.net account nearly that long ago, and then my business got tabled, and so I just pay $$ each month and don't use it.  But *hopefully* before te end of the year I will be online at last and able to collect $$$ !  😎

 

22 minutes ago, Zane said:

Also, I do not consider myself to be anything close to an expert (or even intermediate) level of creating secure systems.

I'm trying, but is a journey for sure!

 

22 minutes ago, Zane said:

I ran a mail server about 6 years ago and that was a total nightmare.  Literally, as soon as the server went live, it was plagued with bots and whatever else that started using my SMTP server as an open relay and my IP became blacklisted pretty quickly for spam.  I google ad nauseum for how to secure this and how to secure that and what the best practices were, but I was in way over my head with absolutely no budget for anything to help me out.  After 4 years of trying to maintain a mail server that successfully sent and received mail with no issues (though, there were still issues), I finally was able to convince my boss to switch to a Google Business account and let them handle all of that guff.

Mail servers are an absolute nightmare that I wouldn't wish upon my worst enemy.  I mean, installing SSL certificates is easier than maintaining a mail server. 

Yeah, I have heard that about mail servers.

On my VPS I have a mail server - I guess - and I don't get anymore spam than on my personal email accounts.  However, it is ultimately managed by my webhost and apparently they do a good job of securing it.

 

22 minutes ago, Zane said:

Anyway, this topic has nothing to do with mail servers.

Rant away - all very interesting and useful in some way to me!

 

22 minutes ago, Zane said:

You know, I've never tried to even perform a breach in my life.  I've never even tried to breach myself.  It's an exhausting realm of web development that I avoid like the plague.

Once my site is up (and making $$), I would like to try and get a penetration testing cert so I will be better able to try and hack my own site and use that knowledge to strengthen it.  But right now I am struggling to get my site done, so one thing at a time!

 

22 minutes ago, Zane said:

Really, what is secure?  Unless you're a Fortune 1000 company or something, I doubt you're going to have a hoard of people trying to hack your site; don't flatter yourself.  I was a web developer and ran probably the least secure site, in my opinion, but the audience for that site was so minuscule compared to that of large corporations.  It's about the same concept as viruses.  Most people running a *nix system do not really need to worry about viruses because *nix systems do not take up much of the market share for personal computers.  However, Windows is always being probed and poked and molested because it has a gigantic user-base.

Yes, you have a point.  Although, the goal is to not remain a "minuscule website" for long!

As my business grows, I'm sure I will be more of a target - people hate to see others succeed and love to knock them down.

 

22 minutes ago, Zane said:

In any case, Authorize.net seems to have improved pretty much everything they had when I messed with it over a decade ago.  Most, if not everything, of what I utilized is gone or deprecated.  I mean, I would trust it.

I think they are considered one of the more secure payment processors, but who knows these days?!

 

22 minutes ago, Zane said:

At the end of the day, though, the most secure you'll ever be able to make your system is if you cut it off from the net.  If it's not on the internet, you really have nothing to worry about.  If you're not connected to the internet, you're not going to get any viruses anytime soon.   I know that's not an answer, but it's a hard truth to accept.  Online banking is really awesome in my opinion, but I know that at any particular time, something could go awry and cause my life hell.

True.  But since I choose to run a business online, I want to do the best job I can to protect things.

And I'm sure it can be done, the challenge is just figuring out where the priorities are at and then getting good advice to firm things up.

 

[kicken]

Your ideas regarding trying to limit accounts based on card numbers (particularly only the last-4) and track individuals by card numbers are fundamentally flawed.

1) Card numbers can be reused over time.   Not sure how common it is or the time frames involved, but it's happened.  So you might be inadvertently locking people out because their card number happens to match one used by someone else 10 years ago.

2) Only checking against the last four digits would have a very high collision rate giving you lots of false positives.

3) Services exist that let you create new credit card numbers on the fly.  Someone could use this to generate as many numbers as they needed.  These services exist specifically so people can use numbers unique to different sites to avoid hacking and tracking problems.

 

[SaranacLake]

29 minutes ago, kicken said:

Your ideas regarding trying to limit accounts based on card numbers (particularly only the last-4) and track individuals by card numbers are fundamentally flawed.

@kicken

If that is all I used, then yes.  But I believe I mentioned AND'ing with things like cardholder name.

Betty Walker in Columbus, OH with Mastercard ending in 9917 would almost always be unique.

Of course if I did all of that, then I'd definitely need to be sure the hashing was secure!

 

@Zane,

I was thinking that while your idea above might solve my problem, a place where it would ultimately most likely fail is that I bet Authorize.net does not allow merchants to retain transaction data indefinitely.  If that was the case - and it seems to me that it is - then I'd need to build my own permanent dataset and find a way to protect it.

[Psycho]

On 10/2/2019 at 8:30 PM, SaranacLake said:

Sorry, I didn't see your replies.

I was asking about passwords.  (What other places would you use hashing?)

I don't like having side conversations not specific to the thread topic,. But since this appears to be more instructive, I thought I'd respond to this question. There are a multitude of uses for hashes aside from passwords. It all depends on the developer identifying a need and implementing it. Basically any time you need to compare complex data. Here are a couple examples:

1. File comparison. For example, let's say you have an application that picks up a file every hour for processing. The file gets written regularly from some process outside of your application. BUT, even though it gets written regularly, it may not have any new data. I might store a hash when I process the file. Then, every hour I will run a hash on the current file contents. If the hash is the same, then I don't process it. There are many use cases where file comparison is needed and where hashing will fill that need.

2. Creating a unique key. In a mp3/music app I worked on, I needed to quickly look for duplicates based on a combination of multiple meta data fields before I inserted new records into the database. Since I was dealing with raw "text" values from the files being process I had not yet determine the unique IDs for some of that meta data. So, I could not use a unique constrain on a single table and it would require a query with multiple JOINs in order to check for a duplicate - on every MP3 file. The processing was executing against hundreds/thousands of files, so I wanted an efficient process. In order to simplify this process, I just created a unique key using a hash on the multiple values and could just check that value against a single table in the DB.

[SaranacLake]

Hashes are commonly used during account registration when you want to verify someone's email.  You create a hash, store it in the database, sne dthe new user a link using that hash, and if they arrive at the email confirmation script with that hash, you activate their account.  In that case, it is treated as a long random set of digits sort of like a password that a stranger could not mathematically guess.