Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I want to allow my customer users to enter their credit card information so that I can charge them every month.
I wonder how one should save this information?
Should it be saved in the MySQL database ("user" table) or is this kind of information too sensitive and need to be stored in another place?
I have no experience of this and would be glad if someone could advice me how to accomplish this.
Thanks.
As mentioned above, do not store credit card information in a database. It's a recipe for trouble. Doing so will make you a very attractive target for hackers and, if they are successful in retrieving them, end your business and potentially ruin your life as well as the lives of those whose credit card numbers are stolen.
Having said that, here are three things to consider:
1) Your best bet is to use a payment processor/payment gateway that offers recurring billing. An example of this is Authorize.Net's Automated Recurring Billing service. Once you set up the subscription they will automatically bill the user every month for you automatically and let you know the results of the transaction. It saves you a ton of work and relieves you of the liability of storing credit card information.
2) If you do store store credit card numbers you must follow PCI guidelines. These guidelines are set by the payment card industry and define what you can and cannot do. It also defines how credit card information must be stored. You will need to encrypt the credit card numbers and you should, but are not required to, encrypt related information (expiration date, etc). You will also be required for ensuring that your web server and network are secure. Failing to meet PCI compliance will result in losing your merchant account and being banned from having a true merchant account forever. That would limit you to using third party processors which are less flexible. Keep in mind that PCI guidelines are a good start but hardly a "how to" when it comes to online security. Your goal would be to exceed the recommendation (by a lot).
3) State and country specific laws supersede PCI compliance. If you suffer a breach and credit card numbers are stolen you risk criminal prosecution. The laws vary from state to state and are constantly in flux as lawmakers are only just beginning to realize how serious of a matter this is.
As far as encryption goes make sure you read up on which encryption algorithms are secure and have not been broken yet. Blowfish is a good start and if you use PHP the mcrypt library is recommended (example).
The safest way is to NOT store the credit card information on your system, but let a 3rd party payment provider do it for you.
It's not required that you use a 3rd party payment provider like PayPal, etc. – but you need to be PCI compliant if you are going to store payment card information. Read this article about BC Ferries, who face substantial fines for not keeping up to date with PCI compliance to grasp how serious it is to be PCI compliant.
My current employer is going through PCI compliance – it's not a trivial process, and requires staff for auditing. Enforcement depends on the country and state/province laws – Canada IIRC requires you to be PCI certified by a PCI employed committee, while some states in the US allow for PCI compliance auditing companies to serve in place of the PCI committee.
Related
I am working on enhancing security in our MySQL database. Specifically, the database stores health information for our clients' patients (so-called PHI), and we would like to separate the patients' names and other identifying information from their health data. What would be some approaches to this issue?
I've thought of one idea: maintain one key for tying the various identifying data together, and another key for linking the health information. These would be mapped to one another with a special "coded key" that would be available only when a clinical user is logged in. Does anyone have thoughts on that approach?
Combining personally identifiable information with health information (dx, symptom, provider, payment, etc) is PHI. Here's a more detailed discussion of PHI. PII can include all sorts of things
In terms of protection of PHI, HIPAA is not prescriptive about it. It's one of the major problems with HIPAA and the reason HITRUST is catching on in the industry. Your reasoning from a security standpoint makes a lot of sense but ultimately security is different from compliance.
At Catalyze we've been through 2 HIPAA audits and 1 HITRUST audit/assessment, all using 3rd party auditors. We architected our APIs to segment PII and health data similarly to how you described. Our auditors agreed with Ollie that the segmentation was unnecessary but felt it was an additional way to mitigate the risk of a breach of PHI. At the end of the day we treat all data on our platform as PHI and protect it accordingly, so for us it wasn't a matter of segmenting data in order to be compliant. In our final audit reports, segmenting PII from health data did not address specific requirements of HIPAA but did get mentioned as part of our overall security posture.
Hope that helps!
I'm trying to understand if a DHT can be used to solve a problem I'm working on:
I have a trading environment where professional option traders can get an increase in their risk limit by requesting that fellow traders lend them some of their risk limit. The lending trader can either search for traders with certain risk parameters which are part of every trader's profile, i.e. Greeks, or the lending trader can subscribe to requests from certain traders who are looking for risk.
I want this environment to be scalable and decentralized, but I don't know how traders can search for specific profile parameters when the data is contained in a DHT. Could anybody explain how this can be done?
Update:
An example that might make it easier to understand might be SO, but instead of running as a web application, the Risk Exchange runs as a desktop application on each trader's workstation. The request for risk are like questions (which may be tagged by contract, exchange, etc) and each user has a profile which shows their history of requests, their return on borrowed risk, etc.
Obviously the "exchange" can be run on a server, but I was hoping to decentralize it and make it scalable so that the system may support an arbitrary number of traders. How can I search for keywords, tags, and other data pertaining to a trader's profile if this information is stored in a distributed hash table?
Your question holds a contradiction in my ears. DHT is a great way of distributing data in a decentralized manner, but cannot provide the nodes with an information overview. This means that any overview action, such as questioning the network for certain data, will have to be done at a centralized collection point. Solutions to this contradiction has been created, but their fault tolerance does not match a critical system such as financial trading.
So my answer would be to use a centralized server to hold an overview cache of the DHT network.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Most of the websites I've used in the past (including this one) do not offer an option to delete your own account.
I think the main reason is to avoid the orphanage of the items created (or the delete on cascade of those items).
Modern sites (like this one) have a place where those items go when an account is abandoned (in the case of SO it is the user "Community").
What is, in your opinion, the rationale of not providing a "delete my account" feature?
Security? Laziness? Ignorance? Bug? Or feature?
We are designing a small web app, and we are discussing precisely this topic. We can't find too many reasons though for not allowing the user to delete the account.
This is a pretty broad topic, but some of the ones I've experienced are:
Accounts can be tied to comments, deleting the account screws up the comments
Accounts can tied to other systems (community server, authorize.net and blackbox web services) and can be hard to delete on those
Cascade, like you mentioned
Prevent user stupidity - accidental delete is hard to undo, and even trickier on a subscription site
Return on investment - try explaining to your boss why you're doing a weeks worth of data integrity testing instead of setting a boolean to false
Marketing - "We have 85,000 registered users" (see: myspace)
Will it be more work to maintain those abandoned accounts than you would normally have? Also, are people that visit your site likely to come back to it after long periods of time? These are questions your team might want to discuss.
Personally, unless it is going to cause a disruption or slowdown in work, I would keep the accounts. That way, users won't complain when they visit six months down the road and find they cannot log in.
This may not apply to you. But in our system, we deal with patient data. Because of privacy, security and regulatory concerns, we do not delete users. We have extensive audit trails indicating who accessed/entered/changed which pieces of information. We provide a mechanism to disable access, but the audit trails must remain in tact, so the health care facilities can monitor and enforce their privacy policies.
I'm pretty sure I've quoted this Udi Dahan article but it's worth posting again here.
The key point is to model the task, not the data. Do you truly want to nullify the existence of a user (he/she never existed)?
I'd say either lack of foresight or "not worth the effort" judgement.
As a user, I want to be able to contact a company and request that my account be wiped.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
We're considering an ESB infrastructure.
When would you consider open source products like Mule and when would you consider packages like TIBCO, BizTalk or Oracle Fusion?
Cost and support are the obvious two distinguishing features.
If you have no money to pay for licenses, then open source is a good alternative.
If you don't like open source because of managerial objections, then you'll go with a licensed product.
With open source, you want to be sure that you're getting something that has some longevity to it. The signs are vibrant developer and user communities, easy access to forum support, periodic updates to the software, standards-based with alternatives available, etc. You don't want to make a choice for something as fundamental as infrastructure and regret it a year later because the open source project has fallen apart.
ESBs can play a lot of roles:
gateway for B2B with external parties
messaging between services
transformation between formats (EDI, XML, etc.)
orchestration of services
centralization of cross-cutting concerns like auditing, logging, metrics, etc.
You'll want to make a careful decision to meet all these needs.
I know nothing of their product, but Loose coupling versus decoupling ... briefly discusses an important point often missed, and one that can bite you very hard later on.
I worry that BizTalk is being taken over by the .Net types within Microsoft, and may be headed in the direction of the closely-bound interfaces of WCF. Read a lot, ask a lot of questions. Don't expect much of open source offerings.
Among other concerns, given the nature of the ESB design pattern, performance is very important. There are many results published out there. Here is the latest round of ESB performance done in January 2013. However in the performance space, it is advisable to run your own performance test and pick your choice, rather than banking on what are published out there.
In addition to performance, ease of use, extensibility, development effort it takes to integrate systems via the ESB needs to be taken into account. Sometimes, you may start the integration with an ESB, and later, as the system evolves, ability to govern the solution, security, ability to monitor, metering and billing, number of connectors supported, will come into picture. So you might want to watch out for the related solutions around the ESB along those lines.
In general, as it is the case with any software, total cost of ownership (TCO) is also key. Sometimes, it would seemingly be less costly to start with one vendor, yet over time costs might proliferate. Specially, supportability and maintainability is important, given the central nature of the ESB use.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I own a small ISV company that consist of 2 people. We sell a single product built using Microsoft web technologies (ASP/VB6, some .NET). In business for a a few years now, and with relatively stable gross revenues in the low 6 figures.
I'm considering selling the company and moving on to something else, but I'm a unclear on the best approach to to take. I'm not expecting a huge price, and I'm thinking of a gross revenue multiplier of 2 (which seems low to me... but what do I know)... so call it mid 6 figures.
Any suggestions on how best to proceed?
note: Though not directly programming related the question may be of interest to developers. I wrote the application, every single line of code (so it's not like a phb is asking). Perhaps the moderators could give the question a bit of time to see if community takes an interest.
When you say you are not clear about the best approach to take, do you mean you don't have any buyer yet ?
If that's what you are looking for, I would go first to your company's network: Who is the other person in the company, does (s)he wants to buy your share ? Do you have external investors who could be interested by buying the whole company out ? Do you have customers who could be interested (they are losing a provider after all) ? Do you have providers who could be interested (they are losing a customer) ?
If none of that works for you, I would look for the "extended" network of your company: Partner in business, if you have any (like a hardware manufacturer if you do embedded software). Look at what other software your customers are buying. If it's a very niche market and as you are sharing a customer, their other providers may be interested in buying you out for having another source of revenue with an already established commercial relationship.
Lastly, what about your competitors in this market ? If they buy you, they will mainly buy your customers' portfolio. But maybe they are willing to expand at low cost via a "merge" with your company.
It seems really like when you are looking for a new job to me: It's about using all your network first before looking somewhere else, as it is where you generally get the best results.
Best of luck.
Consider one of the "Business for sale" web sites like www.bizbuysell.com. They also have a "Find a broker" feature.
Short of that I'd talk to the professionals you use (accountant, lawyer, etc). They may know of someone who is looking for a business to buy.
One think to keep in mind is that some buyers (like me) might be interested in buying the assets of the business (the code, the client list, the good will), but not the company it self. The distinction is a fine, but important one.