SaranacLake

Now that I know that the PHP function, password_hash(), and the hashing algorithm, "bcyrpt" are recommended for best hashing security when using PHP, I have a follow up question... Would it be secure to hash something like "credit_card_used" and "last-4 of credit card" and store those as hashes either outside of webroot on my VPS, or maybe in MySQL? In my OP, and subsequent posts, I am trying to get a better grasp of how "secure" hashing is... a.) Because if my website ever got hacked, I want the peace-of-mind that at least my users hashed passwords are safe - or at least safe long enough for people to reset things b.) Because i would like to do the following, IF, it can be done "securely"... Capture and store as a hash the credit card type and last-4 of the credit card when a customer subscribes on my website, so that I have a way to limit the number of accounts on a given credit card to "2". From what I have read in the past - and this could be outdated - it would take decades to try and crack a piece of data hashed using SHA-512. IF that were true, then at least technically, you could reasonably hash something like last-4 of a cc and be safe. (Whether this is legal is another issue I'd have to research?!)

Masters thesis, no. But am I trying to learn more each day to be a better developer and produce more *secure* solutions, YES!! The advice above is like saying, "Unless you are ASE certified, then you should NOT change your own oil or learn to do basic auto maintenance..." Ridiculous, really. **Edited to add the word "NOT" above!! 🙂

It sounds like password_hash uses bcrypt by default. Would you agree that bcrypt is probably one of the strongest ways to hash something in 2019? Or is there something even better?

The line of code I posted above seems pretty idiot-proof, so based on your response, apparently that is an outdated approach and password_hash() is superior, huh?

Sorry, I didn't see your replies. I was asking about passwords. (What other places would you use hashing?) Currently in my code - which has sat on the shelf for a couple years - I am using... $loginHash = hash_hmac('sha512', $pass . $salt, VINEGAR); Thoughts?

I have a column where I'm a little unsure of the best datatype to use... MEMBERSHIP_PLAN_PROMOTION - id - promo_code - contract_term - unit_price and so on... As I'm sketching things out on paper, for "contract_term" I was going to store values like: "1 month", "3 months", "1 year", and so on... Why? Because it is easier to read and instantly makes sense. However, in the table below, I determine the "contract_end_date" by taking the moment someone subscribes, placing that in "contract_start_date" and then using "contract_term" to calculate the "contract_end_date"... SITE_SUBSCRIPTION - id - member_id - membership_plan_promotion - contract_price - contract start_date - contract_end I had considered changing "contract_term" to an integer representing days, but then that creates other problems... - Days are harder to read, especially if I had a 2 or 3 year contract_term. (Who wants to read 730 days for 2 years, and what about Leap Years?) - Also, Days don't give you an even "offset". For example, I can more easily have my PHP read a "start_date" = #9/17/2019# and then use a "contract_term" = "1 month" and come up with a perfect offset of "end_date" = #10/17/2019# versus adding 30 days to #9/17/2019# and then - depending on the time of the year - possibly being off a day or so. Follow me? So how can I have a column that is easy to read, and yet also makes calculations easy as well? Most likely, I will just have a few choices (e.g. 1 month, 3 months, 1 year) but obviously I want a design that can grow as business needs change.

What is the latest and greatest way to hash data in PHP?

I am working on a website which sells various content, including books/guides in an online format. A lot of people - including here - have stated that they wouldn't make a purchase on my site if I didn't also offer a PDF version of books/guides. (I guess more people read offline than I do personally?!) Right now, I am working on the ecommerce portion so people can browse a catalog, choose a book/guide, add it to their cart, and check out. (Just your textbook ecommerce metaphors.) After making a purchase, when someone logs in, then they can navigate to a gallery which contains thumbnails representing all of the books they have purchased. And by clicking on a given thumbnail, they will be taken to that particular online book which is a series of linked web pages protected from outsiders behind a paywall. I am comfortable with all of this, however I'm stuck on what to do with the PDFs... First off, when someone is in the Product Catalog picking out books and guides, should I give them the chance to specify if they want a PDF version, or should I just give everyone that buys a book/guide both access to the online book/guide PLUS the PDF version as well? Next, for customers who get a PDF, how should I deliver it to them? Do I make the PDF available when they navigate to their online book? Do I build a second gallery which only shows PDFs that have been purchased? Do I leave links to the PDFs up indefinitely, or should I just offer a one-time download? And if so, how would I go about that? In summary, something that seems so simple actually is very confusing the more I think about it. This is probably because I have never bought online books or PDFs before and so I don;t have any examples in my mind to go off of. Could definitely use some advice here, and am hoping this won't be as difficult as it currently seems?! Thanks.

My point was that in the context of my e-commerce tables (i.e. what I listed above) the goal is to identify the ProductID and the unit_price for each product the user wants and to put that info into the ORDER_DETAILS table. User is buying... 1 @ Premium Subscription, 2 @ "How to become Rich" Books, and 3 @ T-shirts. And that info comes from your "main" PRODUCT table as you described above. All of the other things related to different product types can be stored in the related product-type tables.

In the tables below... CUSTOMER --||-----0<-- ORDERS --||-----|<-- ORDER_DETAILS -->0-----||-- PRODUCTS Would you agree that what is really important in the PRODUCT table is a way to uniquely identify the product (ProductD) and to have a description and current price for it?

I wouldn't be here if I didn't think there were people here smarter than myself - I'm talking to one now. But, yeah, that is also why I'm being a nervous-nelly and being skeptical of advice I take and decisions I make. Fwiw, I am *very* confident in what I have designed so far, just wish it wouldn't have taken me years to come up with?! If I can just get my e-commerce module done, then I'm home free and get "go live" and face the larger challenge which is, "is anyone willing to part with their $$ to buy what I'm selling?" Film at 11... 😎 Yes, I understand and agree. But this circles back to my challenges with design... I'm not always 100% certain what I need (or want). Most of the time I have a "vision" of what I want, but sometimes I'm not sure how things work in the real world or what others commonly do or what makes good sense, and so I end up with questions like today. I'm trying my best, but this stuff is complicated!!! ☹️

I agree other than I have made a long career of working for large companies that had poor design and they pay the price the rest of their lives because it is less painful to keep duct-taping crappy design than pull the plug and start over and do it right. Since I am a company of one, I fear really fubar'ing my design and never being able to recover. But I get your gentle "Analysis Paralysis" *hint* 🙂

So the "type" helps your application to know where to do an INSERT? And are you saying that there would be a one-to-one mapping between the PRODUCT TABLE and say a THING_1 table or a THING_2 table?

Alas that is the tricky thing about pouring concrete... Are the footings (and hole) "close enough" to where they should be, or am I gonna be crying when I realize my foundation/driveway is insufficient?! I see your point, but it's a fine line...

So you aren't linking the tables with keys?

😋

I am trying to lay out table for an ecommerce site that sells both products and services. In a simple ecommerce site, you would likely have tables which look like this... CUSTOMER --||-----0<-- ORDERS --||-----|<-- ORDER_DETAILS -->0-----||-- PRODUCTS My problems is that for PRODUCTS, I have to connect to things like Online Subscriptions, Online Books, and then traditional items like Paper Books and T-Shirts. I am thinking that I almost need to use a supertype/subtype for PRODUCTS, but that seems rather complicated to do in MySQL or any database for that matter. Good designs should be simple, but it seems that the nature of what I am selling requires a more complex solutions and I'm not quite sure how to tie in my own table structures to the PRODUCT table so people can purchase products and services all at once?!

So as the customer shops, I would just store the items they choose and the quantities in the $_SESSION? So at what point do you create an Order and populate the Order table? It wouldn't make sense to do that as a person is still shopping. I guess when they click "Proceed to Checkout" I could create the Order record then. But is there any harm in waiting until the click "Process Payment"? I guess one benefit of creating an Order record and child Order_Details records once they click "Proceed to Checkout" is that it is similar to having a persistent Shopping cart. What do you recommend?

Let's say that I have a standard e-commerce setup with the following back-end table structure... CUSTOMER --||-----0<-- ORDERS --||-----|<-- ORDER_DETAILS -->0-----||-- PRODUCTS This may sound dumb, but I'm trying to understand how actions that the user takes while shopping would map to the back-end tables. For instance, when would I start populating these tables? Would I start populating the tables as the Customer is adding items to his/her shopping cart? (Or do I need extra tables for that?) Or would I populate all of the tables at the very end when the Customer submits the order? Or somewhere in between, like when he/she chooses to checkout? I buy thousands of dollars a year on e-commerce sites across the Internet, but that doesn't mean I necessarily understand all of the inner-workings of what happens behind the scenes! Can someone help me get a better grasp on all of this?

Those would work, but I just have this new sense to use the word "entitlement"... 🙂 If I had to split hair, I would say that "entitlements" apply more to features. As in, "Which system features or functions are you entitled to use?" (Being able to modify a post a week after the fact or seeing a member's IP address or banning a member are all "entitlements", i.e. privileges, of an Administrator.) A MEMBER has a SUBSCRIPTION to a MEMBERSHIP_PLAN By purchasing a "Premium Membership", that MEMBERSHIP_PLAN has ENTITLEMENTS to the following SITE_FEATURES (access to archives, access to premium content, ability to message others, etc). On one hand it is all semantics, yet I think "precision" in language is essential to any well-designed system.

Poor analogy... Taking time to understand entities and their relationships and coming up with good names is one of the most important things you can do when designing a system. Almost every problem I have encountered over the last 25+ years is because people didn't take time up front to understand the data entities and their relationships and related processes.

That is what I have. I just started wondering if maybe my SUBSCRIPTION table shouldn't have the word "entitlement" in it to. And so I started pondering whether "Entitlements" relate more to people or to things like site features.

But do you think that ENTITLEMENT applies more to the relationship between MEMBER and MEMBERSHIP_PLAN or between MEMBERSHIP_PLAN and SITE_FEATURE?

Since I'm in the U.S. and we only have one king here, #1 doesn't apply. Yes, #2 is close. Okay, so on to my question... I picked up the term "entitlements" from work where I am often told to call the help desk and request OIM entitlements for a given enterprise system. So I applied that concept to my website since I didn't have a good name for it. Over the last week or so I built a fancy ERD modeling tables related to people subscribing to my website and thus getting access to things. Without posting all the intimate details of my data model, let me say that I create an "Entitlement" table which linked MEMBERSHIP_PLAN to SITE_FEATURE which is a many-to-many relationship. Does that sound like a reasonable use of the term "Entitlement"? Then as part of that, I also needed a way to link MEMBERS to MEMBERSHIP_PLANS and I did that with a "Subscriiption" table. Does that sound okay? The reason for starting this thread is second-guessing myself?! One could argue that a MEMBER has an ENTITLEMENT to a given MEMBERSHIP_PLAN, right? If you agree, then it is almost like there is a need for two Entitlement tables, although I am comfortable with my SUBSCRIPTION table. Thoughts?

If I said that my database has an "Entitlement" table, what purpose would you expect that to serve? (Hint: Not a trick question, but rather trying to see how people use terms and their meanings.)