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.