views:

112

answers:

3

What are the best ways of developing a subscription type website that provides lesson content (like Lynda.com)?

How do you protect the content from download (audio and video)?

What's the best way to handle passwords? Can the user have a login name and password, and then also have an additional password that changes on a regular basis and is distributed by the site to reduce people using other people's passwords?

How do you minimize people sharing their passwords with other people?

A: 
  1. Protecting content is pretty easy: simply write a page which has access to the user's session / security details and check to see if they are authorized to download the file that was requested. You could do this easily with a Java Servlet or any other web platform like ASP.NET, PHP, etc.

  2. I would recommend against this technique of multiple passwords. It's going to be a hassle for your customers. It also creates the perception that you assume your customers are trying to cheat the system. What I would do instead is log all users logins as well as user accesses for a particular file and also log the IP addresses. You can write some code to analyze this data and look for concurrent logins from different IPs. You could also write code to prevent multiple logins as well.

cliff.meyers
+1  A: 

There isn't much you can do to stop people from copying your content. If you want them to be able to view it, then they are going to have to be able to download it. If they can download it, they can save it.

I don't mean to make it seem like it's hopeless, but I'm just trying to be honest here. You could try to detect if someone was running a spider your site on their account, although that may be a little difficult. Maybe restrict them to downloading 1 page every 10 or 15 seconds. And limit it to 50 pages per login. That wouldn't be too noticable to most users, but would severly deter any automatic spidering the user tried to do. Those numbers may need to be adjusted depending on the type of content you are hosting.

Kibbee
Never hassle your customers. There are always ways to get the content hassle-free, and most of those ways would then mean that you don't see money.
Svante
A: 

NOTE: Looking back through this, I see a lot of missing detail and edge cases to identify. I'm leaving it in this form because I think it is useful to provide the sense of it (even though the details are not quite fully-formed) so you can see what you would be in for. You'd need to work through a threat model to have the cases line up properly.

With regard to passwords, you can prevent password sharing by having an authentication process that uses a secure connection (TSL and https:) and that on the client side computes a hash of the user-suppled password along with machine and user-account (the user id with you and the user account on the client computer) associated data. Even if the password becomes known, the hashing function won't produce the correct hash on a different machine or user account.

There is the interesting problem of how the hash (which is what you accept -- you never know the user's chosen password) is established the first time for association with the user id used with you. You'll need something like a unique key provided for the subscription and provided via e-mail handshake at the time of sign-up and initial choice of user id (if different than the e-mail address) and password.

If you use cookies to avoid people having to log in repeatedly, you might want to have encrypted/hashed information in the cookie that ties it to the machine as well as the subscription.

Now, having done that much, you do have the problem of people wanting to be able to work from multiple machines and also needing to reset an user's password so they can choose a new one in place of a forgotten/compromised one. Since this means providing telephone support and other means of reverification of an authentic user, you might want to consider if it is worth the cost to you and if users will consider it worth the cost to them.

With regard to misappropriation of the materials obtained from the site, you have a much harder problem. Encryption won't help much and you often want to allow users to retain material for off-line use, reference while work with the material, etc. What you can do is identify the material as your property and also identify material as your property and as provided to a particular subscriber in ways where it is hard to excise all occurrences. That is a lot of server-side work. Combined with the obvious demonstration of distrust for your subscribers, you might want to reconsider and work to have something more trustworthy and, say, providing something of value that is not reflected in just having the content. Are you sure you want to do that?

NOTE 2: If you are delivering some sort of progression, such as working through courseware and lessons, there are obvious things you can do so that if somehow there are multiple people coming in, if they make any sort of progress, they mess things up for anyone else. The more personalization and progression, the less appealing it is to provide the account to someone else to use. This doesn't prevent retention of the material but any widespread re-use of extracted content has to be dealt with by other means.

orcmid
Even with support, attempting to tie a user to a specific machine is a hassle. Hassled users will not be enthusiastic about payment.
Svante
I agree. I think it is better to use weak but easily-supported authentication and maybe some personalization of delivered content. Anything else should be saved for when a problem actually shows up and is clearly causing harm.
orcmid