Small Businesses and the Outsourcing of e-Commerce? 23
Zzzt asks: "I work at a very small advertising agency & production company, doing various electronic media projects, including small websites. In anticipation of our clients going elsewhere, my boss decided we should offer development services for commerce websites, complete with credit card transactions and the like. For those out there who have created these sites, is it worth it for a small company to take on such a project, considering maintanance, liability, and other issues that will come up? Or should we just outsource the whole thing? For a medium to low-end HTML programmer, are there pre-canned packages that will most of the work for me?"
Not to attack you in particular (Score:4, Insightful)
HTTPS is a joke for e-commerce. No one breaks into a router and sniffs for credit card numbers. They go after poorly secured databases of tens of thousands of numbers.
Re:Not to attack you in particular (Score:2, Interesting)
and let's not forget social engineering. i worked for a place with a major e-commerce site (actually, major in my country alone, but it moved a lot of money daily) and the security was once compromised because someone called tech support and asked their e-mail to be changed. this was done by the support 'technician' right away, and the attacker then used a 'forgot password' form to get a new password for the account. (the password remember question/answer mechanism is a joke since most people use dumb questions such as 'my dog's name' and other sort of easy to brute-force-attack data).
my bottom line is that whatever process is involved in e-commerce, security is important not only in your servers but in your people, and tech support folks have a series of ugly qualities:
- are scared of their boss and will try to please the customer (even if he/she is no real customer) fast as long as the call doesn't escalate
- have low wages and are usually rotated frequently (every 3 months in the place i mentioned) for 'security' reasons (i guess the intention was to keep security lax)
- tend to think they know more than the sysadmin/programmers/DBAs about how the system works
finally, security procedures are usually not well documented or not documented at all, especially if the IT department is small or unimportant in the jerarquic structure of the enterprise.HTTPS/e-commerce (Score:2)
HTTPS is designed to secure the path between the client browser and the web server. The web server is the one that owns the cert. In general, this path is already relatively secure. Sure, it doesn't hurt to have HTTPS in place, and because it's designed to be (relatively) cheap and easy for busineses to run down to VeriSign and get a cert and set up business, it's quite popular.
This does not address security on the web server itself, which is probably the weakest point. If someone can attack the web server, at the very least they can start snagging credit card numbers.
Second, if the web server is compromised and arbitrary data can be sent to the back-end database, bad things may happen. In a proper setup, the database and the web server are separate systems (ideally with a direct link connecting only the two), and *any* communications from the web server to the database/back end system should be given no more weight than you would give to data coming from a client. Then the back end system validates everything coming from the web server.
The problem is, this sort of thing is much more of a pain to do properly. So we get the ever-so-common situation in the security world of taking the easy, sellable, mostly-useless route. Firewalls (which then are promptly tunneled through with Web Services), HTTPS. Sheesh.
If the security industry really cared about securing e-commerce (their emphasis is on easy-to-set-up and easy-to-sell), there would be standards in place for end-to-end signed stuff, rather like international banks to. The *back* end system has a certificate for *Foo Corp Retail*, and a signed message (in a standard format) granting a transaction for $500 payable to Foo Corp. It goes from the client to the webserver, which can't do anything to it, and ideally couldn't even read it. The web server hands this fund transfer authorization over to the back end system, which then can use that to tell the credit card company or bank to do a transaction. Finally, a cryptographically signed recipt is handed back to the web server, which hands it to the client. Then you get an actually meaningful recipt, instead of a forgeable printout of some webpage that's just handed to a customer to make them feel like they're being taken care of.
Incidently, this also means that there is no reason to send the credit card number -- the remote host has an authorization. They don't need a name, number, or expiration date...just an authorization.
All the people that have tried to do things like this have had dollar signs in their eyes, and tried to take a percentage of the transaction. A percentage of e-transactions is simply not going to be acceptable to the world.
So, until such time as some security firm can settle for coming up with a standard and not trying to monopolize it and take a percentage, here we languish, with the almost pointless HTTPS giving the remote person a little "lock" icon in their browser. Lovely.
The other problem is that any serious security folks that want to implement this usually get bogged down in peripheral issues. Maybe it's putting smart cards on everyone's computer to get a totally secure path (card generates fund transfer authorization), or maybe it's trying to come up with value-added services so that the customer has some *additional* reason to buy the thing. They then get tied to the security system, and you have to sell users on the extra services to get them to use the system.
What we need, right *now*, is a secure system. The current one is atrocious, and until the rate of people swiping credit cards from databases and committing fraud is so high that insurers find it worthwhile to give large benefits for implementing things like this, it's not going to change.
Sigh.
Re:HTTPS/e-commerce (Score:2)
Last time I had to solve this problem, I did it using a nonroutable protocol between the web server and the machine that processed payments. In that specific case, an RS232 lead and some extremely simple and hence limited software on both ends. There was simply no way to access the payment processing machine for anything else except by going to sit in front of it - it didn't even have a NIC in it, just an ISDN line to the bank. If anyone did r00t the (Solaris) web server, the most they could do would be to mess around with the HTML, since there's know way (that I know of at least) to compromise an NT server via its serial port.
Outsource billing only (Score:3, Informative)
a billing gateway, so go for one of the many alternatives out there (authorize.net, fraudless.com, trustcommerce.com, et al).
as for the rest of the e-commerce development (shopping cart, tracking requests, etc), i've used osCommerce (oscommerce.com) with sucess. AFAIK, it's the most complete open source e-commerce suite out there, very well written (it's php code), and easy to extend (you can write your
specific modules for billing, shipping, etc).
has both a public part (called the 'catalog') and an admin interface for the
merchant (this one allows tracking of users, orders, products, etc).
check out the oscdox.com site for documentation
on installing and customizing the package
(note: i'm not related to them in any way, i'm just a satisfied programmer:)
happy hacking
osCommerce looks great! (Score:3, Interesting)
osCommerce looks great! This is what the world needs, in my opinion, a standard method, so people don't have to invent their own. This is the first time I've seen it, so thank you nandix and Slashdot.
However, the osCommerce documentation and source sites are disorganized enough that it seems like osCommerce is not ready for wide use. For example, the documentation project site calls the software by a different name than the software site: OSCommerce vs. osCommerce.
OSCommerce 2.2CVS Documentation [oscdox.com]
OSCommerce 2.2CVS Pretend product catalog [oscommerce.com]
Short description: About osCommerce [oscommerce.com]
830 sites [oscommerce.com] use osCommerce, and are registered.
Re:osCommerce looks great! (Score:2)
Outsource... (Score:2)
Should you attempt to do it yourself: no.
There are a ton of pre-canned packages and such, and you probably might be able to "slide out" a site or two... but it will be crap compared to what a professional would produce, and you would be doing a disservice to your client. Best to hire a independant cheap professional who can bring the graphic and hosting components to the table for you, so you don't need to worry about any of the web related stuff. You need to focus on doing what you do well (advertising agency & production I hope) and let other people do what THEY do well. Specialization is a good thing.
As someone who's done this... (Score:5, Interesting)
Run the numbers, though. You should be able to hire someone with e-commerce experience specifically to implement this. You want someone who knows the space, how can pick a good off-the-shelf system and customize it for your clients, and who is security-conscious. As someone else in this thread said, HTTPS and certs are blue smoke and mirrors compared with unpatched or poorly-maintained servers.
Bring this up to your boss and see how much he *really* likes the idea. With the prospect of paying a new hire (or a contractor) to work on this, he'll either get more serious or less serious, both of which are good news for you.
The distinction... (Score:2)
In-house is profitable.
You choose.
Outsrourcing security ? Bad idea ! (Score:1)
My advice if you have, even only a little, experience or competence in programming related to programming security, go for in-house, you won't regret it (see in 5 years
In-house is more work, at least for the start, but will prevent you from a lot headaches ! Especially for small companies outsourcing is dangerous (if it's related to the main business), 'cause the power of small companies is flexebility, outsourcing will break this !
Hope this can help you decide !
You're ready for this if... (Score:2, Insightful)
Your willing to put your cc number on it, as well as your boss's, your mother's, a wealthy relative, all of your friends including the stock broker guy who survived the market.
Then post the URL on slashdot for security testing.
If you are confident your skills will prevent the compromise of the site, you're too inexperienced, but hey post that url anyhow.
I hate getting involved in this sort of work, there's just too much to go wrong and to secure it the way I prefer to costs more money than anyone is willing to spend.
My advice: stick to advertising (Score:1)
Find a partner (Score:3, Insightful)
Developing in-house capability is hard - you need to have a bunch of expensive techies running around, someone to manage them and the client, and you get stuck with maintenance and support issues ("we're such a good client, could you not just change it for free ?").
I would look around for a local software development shop - ideally around the same size as you - and form a (more or less formal) partnership. If you have customers who want e-commerce capability, you bring the customer relationship, branding capabilities are and account management. The technical partner brings project management, technical skills and maintenance/support capacity.
That way, you are less likely to end up with unhappy customers - at least if you choose a decent partner - and you don't have to invest a lot of time, effort and money in an area you're not equiped to exceed in.
Read "eXtreme programming for web projects" to see some of the joy that awaits you - even if you do look for a partnership...
Yahoo Store (Score:2)
A correct program in a correct env? Re:Yahoo Store (Score:1)
Why not a partnership? (Score:1)
As always, it depends... (Score:2)
Your question sounds more like you're talking about developing e-commerce sites, as opposed to setting up your own gateway, or handling the hosting as other posters have assumed. (I'd agree you don't want to get anywhere near those two things, for the liability issues, if nothing else).
There are some very good e-commerce packages out there (Yahoo store is not one. I'll save you the rant unless you want more details). Someone mentioned oscommerce, which I've not used, but I have looked at it, and it seems viable. Interchange (sorry, no time to find the link) is another excellent solution, especially if you have in-house perl experience.
What this really depends on is how much in-house web development experience you have. If it's just been the occasional static HTML brochure site, with wizzy flash and multi-media stuff, you're in for a steep learning curve, and you're probably better off partnering with a local firm that specializes in web development. With any decent e-commerce site, you're going to be doing a lot of custom coding to get it to do what you want, no matter what package you use. No client ever wants just what the canned package offers, you'll nearly always need to extend it somehow.
Yahoo Store... (Score:2)