Search Our Site

Our Newsletter

Our Ramblings

Which website shopping cart?

We have recently undertaken a study to determine which of the many shopping cart systems we should use on a customers website. After a long process trawling through the myriad of options we finally reached a shortlist of 8 candidates.

These candidates were:

  • Avactis
  • CS Cart
  • Cube Cart
  • Magento
  • OS Commerce
  • Prestashop
  • Virtuemart
  • Zen Cart

Now, with that part done the hard work begins.

The fact of the matter is that all of the choices in the list above are great ones. Any of these shopping carts will, with the right implementation, produce an excellent level of functionality on any website. The trick is to understand your own requirements first and identify which of the options most closely fits your own requirements, not only today but also your anticipation of what they will be in 6 months, 1 year and possibly even more.

So lets look at the pros and cons of each.

You can find the comparison HERE.

 

How Does Secure Socket Layer (SSL or TLS) Work?

The Secure Socket Layer, SSL for short, is a protocol by which many services that communicate over the Internet can do so in a secure fashion. Before we discuss how SSL works and what kinds of security it provides, let us first see what happens without SSL.

Life on the Internet without SSL

Let us compare communications between computers on the Internet and communications between people over the telephone. Without SSL, your computer-to-computer communications suffer from the same security problems from which your telephone communications suffer:

  • Who are you talking to? In a phone conversation, how can you be sure that the person who picks up the phone at the other end is really the person you are trying to call (especially if you have never spoken to them before)? What if your phone call was intercepted or re-routed, or what if someone else is answering your call recipient’s phone? There really is no way to be sure you have reached the right person, especially if they are actively trying to fool you.
  • Eavesdropping? As you are aware of from watching TV or reading, it is very easy to tap phone lines: the police and spies do this all the time to covertly gather information. It is not easy to detect if your lines are tapped. The same applies with communications over the Internet — how can you be sure that your communications are not being “tapped” and recorded?  This is especially problematic in public wifi hotspots.

This results in two very real security issues for communications over the Internet: 1. knowing for sure that you are connecting to the right servers  (i.e. those at your bank and not those at a hacker’s or phisher’s web site), and 2. knowing that your data is safe from prying eyes during transit to those computers. This is where SSL comes in.

Enter the Secure Socket Layer (SSL)

To solve these problems to a large degree, most Internet services support use of SSL as a mechanism for securing communications. To illustrate how SSL works, let us use another analogy.

Client wants to communicate with a company to send important information back and forth. Client wants to be 100% sure that s/he is communicating with this particular company and that no one can eavesdrop on or intercept the communications. How can s/he do this?

  • Client sends a courier to the company’s address.
  • The company has envelopes that, when closed, can only be opened by the company. The company and the courier go together to a trusted third party — a notary — which makes the company provide documentation to prove its identity. The notary certifies the company’s secure envelopes and the courier takes these back to the client.
  • The client gets the envelopes and, if it trusts the notary’s reputation, can be sure that they are actually from the company indicated.
  • The client also has secure envelopes that, once sealed, only the client can open. It puts some of these in one of the company’s secure envelopes and sends them back to the company.
  • The company gets the sealed secure envelope. It opens the envelope (as only it can). It now has the client’s secure envelopes.
  • The company has another kind of envelope that can be opened and sealed only by using a special combination. The company puts this special envelope with the combination lock, together with the combination, into one of the client’s secure envelopes. The company seals the envelope.
  • The company has another type of secure envelope that anyone can open, but which only the company can seal. If you open one of these sealed envelopes, you know for sure that it was sent by the company. The company puts the whole package inside this and sends it to the client.
  • When the client gets the secure envelope, it opens it and thus knows that it came from the company. It then opens the next secure envelope inside that can only be opened by the client. Inside it gets out the combination-envelope and the combination itself.
  • The client the puts his data in the combination envelope, seals it and sends it to the company.
  • The company receives it, opens it, and puts the response in the same secure envelope and sends it back.
  • The procedure is repeated as often as necessary for required communications.

SSL relies on the concept of “public key cryptography” to accomplish these tasks. In normal encryption, the two parties communicating share a “password” and that password is used to both encrypt and decrypt messages. While this is fast and efficient, how do you communicate these passwords to people you have not yet met in a way that is itself secure?

In “public key cryptography”, each person has two keys — a “public” key and a “private” key. Anything encrypted with the user’s public key can only be decrypted with the private key and vice versa. Each person then tells the world what his public key is and keeps his private key safe and secure, and private.

If John sends Mary a message encrypted with Mary’s public key, then only Mary can open it, as only she has her private key. This is like an envelope that anyone can seal but which only Mary can open.

If John sends Mary a message encrypted with John’s private key, then anyone can open it, as everyone has access to John’s public key. However, successfully opening the message proves that it was sent by John and no one else, as only John has access to his private key. This is like an envelope that only John can seal, but which anyone can open and thus prove that John sealed it.

SSL in Action

So, let’s see how SSL actually works for securing your communications over the Internet. Before the communications occur, the following takes place:

  • A company wishes to secure communications to their server company.com.
  • They create a public and private key for company.com (this is also known as as “SSL Certificate“).
  • They go to a trusted third party company such as Thawte or Verisign: Thawte makes the company prove its identity and right to use the company.com domain. This usually involves a lot of paperwork and paying a hefty fee.
  • Once the verification is complete, Thawte gives the company a new public key that has some additional information in it. This information is the certification from Thawte that this public key is for the company and company.com and that this is verified by Thawte. This certification information is encrypted using Thawte’s private key… we will see why below.

Then, when Client wishes to communicate with the company at company.com,

  • Client makes a connection to company.com with its computer. This connection is made to a special “port” (address) on company.com that is set up for SSL communications only.
  • When Client connects to company.com on its SSL-secured port, the company sends back its public key (and some other information, like what Ciphers it supports).
  • Client gets the public key and decides if it is OK…
    • If the public key has expired, this could be a problem
    • If the public key claims to be for some domain that is not company.com that could be a problem.
    • Client has the public key for Thawte (and many other third party companies) stored in its computer — because these come with the computer. Thus, client can decrypt the validation information, prove the validation is from Thawte and verify that the public key is certified by Thawte. If Client trusts Thawte, then Client can trust that he/she is really communicating with Company. If Client doesn’t trust Thawte, or whatever Third Party company is actually being used, then the identity of who is running the computers to which Client is connecting is suspect.
  • If the client doesn’t trust the server, then the communication is terminated.
  • If the client has its own SSL certificate installed, it may send that to the server at this point to see if the server trusts the client.  Client-side SSL certificates are not commonly used, but provide a good way for the client to authenticate itself with the server without using a username or password.  In the case where this is used, the server would have to know about the client’s certificate and verify it in a similar way to how the client verified the server.  If this fails, the connection is terminated.  If a client-side certificate is not needed, this step is skipped.
  • Once the client is happy with the server (and the server with the client, if needed), then the client choose an SSL Cipher to use from the list of encryption methods provided by the server, and generates a “symmetric key” (password) for use with that Cipher.  The client encrypts this password using the server’s public key and sends it back to the server.  The server (and only the server) can decrypt this message and get this password, which is now shared by both the client and server.
  • The client will then start communicating with the company by encrypting all data using this password and the chosen Cipher. Normal “symmetric” (password-based) encryption takes place from this point forward because it is much faster than using the public and private keys for everything. These keys were needed to enable the company (and possibly the client) to prove its identity and right to domain.com and to enable the client and server to generate and securely communicate a common password.

So, Are there Limitations to This Process?

This all sounds great — what are the down sides? There are a few.

Key Length: The statement that “only someone with the private key can decrypt something encrypted with the public key” is true so long as the private key cannot be “guessed”. Hackers may try to do this by trying all possible private key combinations. Older “40bit” keys can be broken by trial and error if one has access to vast computer resources and a good amount of time. These days, keys used in SSL are 128bit or better. There are so many possible keys with 128bit that it would take significantly longer than the age of the universe to “guess” one.

Trust: While use of SSL ensures that your communications cannot be spied on, it comes down to trust to ensure that you are actually communicating with your intended company. This is reflected in the validation of company.com and your trust of the third party organization. Some “secure sites” do not bother to get a third party’s approval and have their keys approved by “themselves”. Others use third parties that are almost free and which spend very little effort in validating the company. In these cases, SSL provides you with no real assurance that you are really talking to your intended company and not some hacker trying to forge their identity to communicate with you in a manner in which you think you are safe.

For defensive use of the web, you should pay attention to warnings generated by SSL when you connect to secure sites. Such warnings include “expired certificates”, “domain name mismatches” — where the domain name presented by the company is different than the one to which you are connecting, and “non trusted certificates” — where the public key (certificate) presented by the company was not validated by a third party that your computer trusts. In all of these cases, you should be wary.

Ciphers: SSL uses one of a large variety of possible “ciphers” to perform the symmetric encryption.  Use of a poor/weak cipher can result in fast SSL that is easily compromised.  Currently, it is recommended that one use 128-bit or stronger AES encryption as your cipher.  See: 256-bit AES Encryption for SSL and TLS: Maximal Security.

What Services Can be Protected With SSL?

Almost any Internet service can be protected with SSL. Common ones include WebMail and other secure web sites such as banking sites and corporate sites, POP, IMAP, and SMTP. LuxSci provides SSL services to protect your username, password, and communications over all of these and other services.

The Importance of Video to Unified Communications

Enterprise Connect was held last week in Orlando. Among what seemed to be a great deal of interesting presentations and tutorials was a discussion on the role of video in unified communications.

John Bartlett, the principal of NetForecast, posted at No Jitter on a presentation entitled “UC in 2011: Myths, Realities and What Comes Next?” He started out by paraphrasing Phil Edholm, vice president of technology strategy and innovation for Avaya, who suggested that video is more important when the session is persuasive in nature, as in a sales call.

Bartlett wrote that John Del Pizzo, program director for IBM’s Unified Communications and Collaboration Software, disagreed. Del Pizzo said that the need for video extends to any communications in which it is important to get feedback. On a more pragmatic level, he said that video can focus a meeting by, for example, keeping participants from multitasking.

Edholm ended with his own viewpoint:

I think to understand these use cases we need to go back to the basic social instincts of humans and how we were designed to communicate. We do best in small communities where we know the people and we can judge how they will react to what we say. We get a lot of that information visually. I think what video conferencing does for us is allow us to more quickly form those small communities even though we are not co-located. Once we have been able to form the social connections to the group, the group can then be much more productive in its work because we know how to communicate.

Clearly, video is the next big thing in unified communications. It’s interesting to read about folks who spend much of their time on the technical issues related to adding video to established unified communications platforms change pace and discuss the topic from a more theoretical point of view.

Their points are well taken. There is essentially no communication that isn’t better with video. There may be specific cases where it isn’t ideal, such as the incremental benefits not being cost-justified or cases in which participants don’t want to be on camera — or doesn’t want his or her work area on camera. The bottom line on video remains clear: It is coming and coming quickly.

Contact us today to explore the many ways in which we can help your business adopt and exploit this technology.

B2B: Why You Need It And How To Achieve It

B2B connectivity is no longer a luxury; it’s a necessity in order for a company to remain competitive. B2B integration enables a company to focus on its core competencies and offload other services to partners in order to gain efficiencies and reduce cost. Companies today operate in a global business environment. They don’t live on an island; they need to interact not only with their suppliers but also with their trading partners and customers, all of whom may be distributed throughout the world.

After spending the greater part of the past decade purchasing expensive ERP systems, Customer Relationship Management, and e-Commerce applications in a departmental manner, companies are turning their attention to integrating these information silos and looking beyond the corporate walls for new opportunities to eliminate costs and gain a competitive advantage.

Companies need to embark on three distinct initiatives for creating and deriving value from an extended enterprise. First, optimizing internal processes; second, reducing transaction costs; and finally, enhancing supply chain efficiency.

Optimizing Internal Processes

A primary reason for building e-business integration initiatives internally is that value chains are only as strong as their weakest link. Devoting extensive time, resources, and capital to B2B projects will seldom yield substantial return on investment if internal systems are not integrated. B2B initiatives such as e-commerce and procurement often fall outside the capabilities of ERP software. To compensate for ERP’s shortcomings, companies purchase other applications, build custom applications, or rely on legacy applications. Although they provide significant value collectively, these disparate applications build thiefdoms of information that cannot be easily shared, contributing to business process bottlenecks and inefficiencies.

Companies that try to integrate these systems on a point-to-point basis get what Gartner calls ‘spaghetti code.’ This is one reason companies spend up to 35 percent of their software maintenance budgets on simply maintaining these connections instead of focusing on their core competencies. Simply connecting applications on a point-to-point basis is not enough. Without a thoroughly integrated internal infrastructure, B2B initiatives are sure to provide little value in the best-case scenario, or no value in the worst.

To fully achieve the kind of business process visibility required to gain true insight into the enterprise and supply chain, companies must rise out of the thiefdoms of information and departmental approaches to conducting business. They need the ability to define enterprise business processes that can span across multiple systems and business partners that reside beyond the firewall. These processes are independent of any particular application and should support open industry standards of business process and portability.

The answer involves standards-based Business Process Management (BPM) and Business Activity Monitoring (BAM) software that, among other benefits, reduces the amount of always-expensive human intervention.

In order for a system to provide real-time Business Activity Monitoring, it needs to have a common metadata repository and an events repository that caches all the relevant events in real-time. This repository can be accessed in real-time to gather insight into a business process. A user needs to have the ability to define key performance indicators (KPI) to monitor, and associate them with specific events. This enables real time visibility into processes and KPIs.

BAM has the ability to drill down into the process in real-time to identify bottlenecks and either notify the application administrator to fix the error in the system … or simply change the business process to make it run more efficiently.

Reducing Transaction Costs

To reduce transaction costs, companies need to focus on three initiatives: reducing (always expensive and often error-prone) human interaction to managing by exceptions, leveraging the Internet as much as possible for conducting transactions, and supporting industry-standard protocols that not only define the document exchange format but also automate the process of communications between trading partners.

Enhancing Supply Chain Efficiency

Collaborative commerce is a non-linear, near real-time, many-to-many flexible technology platform that creates an extended enterprise where suppliers, partners and customers can share, modify and act upon information and processes.

One benefit? Better-managed and less expensive inventory as information takes the place of physical inventory. Another? Transferring active leads to partners better-equipped to act on them.

To drive down costs across the entire value chain, partners must define their business processes across the entire enterprise, enable two-way visibility of both supply and demand information across the value chain, and consider tight integration with partners’ back-end systems.

While the rewards of B2B are considerable, there are barriers to success:

  • Without internal visibility, internal bottlenecks and inefficiencies simply replace external ones.
  • Managing a diverse group of trading partners — potentially supporting a variety of business communication protocols — is a daunting task.
  • Security is required to protect potentially sensitive information; partners must provide a message-tracking system to prove that transactions actually occurred.
  • Adoption, support and establishment of industry-standard protocols for conducting transactions, especially when moving beyond exchanging transactions to actually sharing business processes.