Context is Learning Systems….
This is a quick primer on the differnces between Authentication, Encryption and APIs/Communciation Protocols. I will try and explain each in simple terms, and the importance of all three.
At its basic sense, authentication is simply a way for a web server to verify a user is who they say they are…and to keep “riff raff” out. Most people know this as simple username/password prompts. An LMS or content server with an authentication scheme employed will require an individual to identify (login) before they are allowed into the system. Now some Authentication schemes, like Single-Sign-On (SSO), will be integrated with either your local Operating System or browser to store credentials that you have entered earlier, and share that with other SSO enabled sights. From an end-user perspective, it appears they may not be authenticating on a particular site…but be assured…they are…it is just automatic.
If a site does not provide authentication…then by definition, the site is open to the general public. You may have heard of the term, Security by Obscurity. This simply means…if a person does not know it is there..then it is secure. And this is false. Would you bury your life savings in a forest preserve if I could guarantee that no one knows the location? I would hope not. You always run the risk that someone may accidentally run across your hiding spot…or an enterprising individual may try and discover this location by following you during one of your withdraw runs…or discovering through social engineering (maybe talking to a family member that discloses some information that might lead an invidual there). You want your money in a secure location like a bank, that checks your identification and requires some additional information like an account number before you are allowed to withdraw the money.
Encryption is simply protecting the information that travels from the server to the end-user’s browser, encrypting, or scrambling, the data so only the server and browser can understand it. You should realize that computer networks are just a medium to transmit data, just like yelling across a room. Next time you are at a Starbucks, imagine your Bank is next door. Would you yell out loud to the bank teller, asking for a withdraw and then yelling your account number and maybe social security number for all to hear? Of course not. Well, sending this information across the internet, although not as blatent as yelling, still provides the same information…just slightly more difficult to listen into. But going over a wireless network IS broadcasting that information in about a 300 ft. radius, and people could have listening devices picking up on this information. Also, anyone with access to network connections anywhere between you and the destination server could tap into this information as well. Pretty scary thought, isn’t it.
The standard encryption scheme used by Internet sites is Secure Sockets Layer or SSL. You can tell if you are using a SSL site in general if the URL starts with HTTPS (that “S” means secure) instead of the more standard HTTP sites (no-secure). With SSL sites, when the SSL server and your browser initially connect, they agree on a complex protocol to scramble all the data as it leaves your browser and travels to the server, only to be unscrambled at the other end…and this happens both ways. So even if you are “yelling” your bank account information, it is in a language that only your browser and the bank’s servers can understand. So any site that is SSL enabled, will safely communicate all information in a protected and safe way.
Within the context of learning environments or LMSs, there are two primary APIs or Communcation protocols used; AICC and SCORM. SCORM is really just an extension, and really just version 3.0 and later of AICC. The purpose of these standards is twofold. First is to provide a standard mechanism to package up courses and configuration files in a way that LMSs can consume, load and configure the course on the LMS. The second purpose is to provide an agreed upon communciation approach so the course can talk to the LMS to get basic student information, get previous progress data, and send completion information. Nothing more. There is nothing in the AICC or SCORM standards that deals specifically with protecting course data from prying eyes – no Encryption or Authentication is defined in these standards.
Encryption does not Equal Authentication
I can enable SSL on a site that is open to the general public, with no login. In fact, go to HTTPS://www.google.com. You will notice (although not physically see) that all your Google searches are encrypted and no one will be able to see that I executed a search on say ‘pink flamingos’, but ANYONE can get in and execute a secure search on Google. Not much benefit in SSL securing a site that anyone can get to the information anyways.
There were a number of sites that used to require authentication, but did not provide encryption. eBay I believe early on was this way. You were required to enter your login information to bid on items, but if someone could view your traffic, the could have easily gotten your login information and/or seen what you were buying. So you will notice now that on ebay, as soon as you go to the login screen, you are redirected to their secure SSL enabled site.
There is security in enabling both authentication AND encryption, and most (hopefully all) financial institutions will require both. So if you care about protecting the information on your server, whether it be financial information or Intellectual Property for your company, you will want to secure your data with both encryption and authentication at a minimum.