Subscription Systems [Technical]

This forum will contain various articles contributed by the team and other invited guest.
Post Reply
User avatar
Jay
Will work for food (Administrator)
Posts: 3020
Joined: Mon Jan 14, 2002 12:48 am
Location: Next Door
Contact:

Subscription Systems [Technical]

Post by Jay »

Intro
The question of whether or not to go subscription on a stream is purely up to you based on your needs as a business and it typically relates to the desire of an end user to have access to this content and purchase or trade services for access to this content. Content that can fall into this range is typically of an exclusive nature. It is typically not a wise decision to consider content available through other sources free as a potential subscription stream. You could also do a bitrate/quality teiring system, where they get higher quality for paying a subscription fee.

Authentication Methods
Differing forms of authenticating the user are available to you. Some systems are good approaches and some are bad. I will try to focus on both and explain the technical reasons why each method is bad. First the good methods.

HTTP Authentication
The authenticated stream is the most accurate and reliable way to handle subscription based systems. Stream authentication is typically done by doing an HTTP Authentication. An HTTP Authentication is the same method used by websites to protect their content from uninvited users by purely passing authentication requests and responses via the HTTP header. You typically see this in the form of a popup window in the browser\'s native windowing system, not in an HTML form. Media players which support this method also display their own login form, but with varying degrees of usability. Unfortunately for media players which do not support this method a user is incapable of using the stream unless they can embed their info in the url as part of the user:pass@domain scheme. Well designed players will support this at the very least. If they do not they are not following HTTP protocol!

Query Authentication
This authentication method is similar to a web or HTML form passing user and password details via the url or post form. Typically for this to be usable a system would handle the query in GET fashion, such as: http://domain/?user=myname&pass=mypassword The good thing about system that follow this basic capability means that most if not all players will be capable of tuning in because the user can pass their credentials via the url. The negative effects are that a middle man system such as a proxy can cache or perhaps store their credentials to a log file which may expose their details to unauthorized users. This is not something that most people typically concern themselves with but it is worthy of the note.

The bad and the ugly
There are some systems which I highly do not recommend for stream systems which over the years have made their way into some people\'s systems. This is typically due to misinformation that is usually attached to such systems. Before I get into these systems too heavily I wanted to make mention that I highly recommend the use of servers which are specifically designed to handle authentication of users. As of this writing those systems were Windows Media Services, Steamcast, and Icecast 2.x. SHOUTcast 1.x is NOT a server which can ever in any form handle authentication, at least not in any usable way.

The first is the tpepper script, which Tom Pepper wrote years ago as hack authentication to work around the fact that AOL/Nullsoft had not interest in giving away for free, the ability to authenticate in their product. This is a PHP script which is placed on an average webserver which you give your listeners the address to. The script then does an HTTP Authentication and if successful pipes the audio to the user. You are probably thinking, \"Jay, you said HTTP Authentication was good!?\". Well, I did, and this script demonstrates it well but the problem here is you now loading down two servers for audio streaming. The first is the original server and the second is the Web server hosting t.pepper\'s script. If you have limited transfer capabilities through your web host, I have news for you. You’re racking up your bill, because now you have an incoming and outgoing connection for each and every live listener on your webserver. PHP and most web servers were also not designed for this type of activity either. In a perfect world we could magically move the user to the shoutcast server quietly and discretely and have it just suck up bandwidth there instead but this isn\'t a perfect world. Many have attempted to hack this script to refer the user to the actual stream location. You have now just given away your free stream address to the end user and they can now listen whenever they want without authenticating, so that doesn\'t work either. Don\'t even try just doing a Location header to bounce them discretely because netstat will tell them who they are really connected to. This brings me to my next point. Web based forms and authentication methods to give the user a playlist or address to the stream are generally bad because you have lost the ability to manage the user. They can now give that url out to their friends and family and unsuspectingly kill your entire reason for making a subscription stream in the first place. Don\'t trust these easy quick fixes and security through obscurity concepts. Its bad practice all the way around. Unfortunately many still see this as an ok thing to do and unfortunately many stream and content providers are not aware that their systems are completely open to the world. I cannot stress this enough so I will bold face, underline and cap it. DO NOT TRUST ANY SYSTEM THAT DOESN\'T HANDLE AUTHENTICATION AT THE ACTUAL SERVER!!!! It is a waste of your time, money and effort.

Which stream systems can effectively handle my subscription stream
Unfortunately there is no end all and be all solution yet. I am hoping that steamcast can be there eventually but it isn\'t all the way there yet. It’s close though, but accounting is not at all apart of most stream systems. You won\'t be able to put this together without some piecemealing of several systems.

Windows Media
Windows media is the defacto for windows based broadcasting because of the low barrier of entry for the listener. It literally requires almost no effort on most users’ part to get to your stream and get authenticated via this system. I highly recommend it if your target is windows users. This system isn\'t as open to the alternative OS end user though.

Steamcast
This is our very own server. A SHOUTcast clone with many features that I felt was missing and integration of icecast2 capabilities, an all-in-one for the alternative cast servers. Works with virtually any player and any codec supported by SHOUTcast or Icecast2. The downside of this system is it is still beta and still being developed.

Icecast2
Open source SHOUTcast clone that went its own route. Very similar to Steamcast but has a few more and differing options.

What about accountability?
This is where you would pretty much have to brew your own. There may be some open systems but I am not aware of them. It is fairly trivial to tie into Icecast or Steamcast though. Basic knowledge of PHP or PERL could tie a steamcast or icecast server to a mysql database allowing you to completely control when users are allowed on the system. I would envision such a process being done via cron or daemonized script process in which the script checks the database for users and how much time or credit they have left and once used up remove them from the authenticated users list. With steamcast this is trivial because the list is just a txt file at this time. Steamcast also provide all the information the script would need to know who is logged on and how long they have been on for.

It certainly isn\'t easy if you just want this system without getting your hands dirty, but it certainly isn\'t as hard as it used to be.

For windows media there are systems available to tie in and do this all for you.

Conclusion
It\'s important that you understand the differences between obscurity and true security. Don\'t cheat yourself. If you can think of ways around any system you have or are thinking of then it probably is the wrong way to go. Going subscription for some streams can be an extremely lucrative way to go. I would think long and hard about the intentions and your goals before making that move if you have an already existing free stream.

Feel free to leave a comment if you feel that I have missed something. Do not reply with questions. Questions should go in the Audio Streaming forum. Questions will be split from this thread and moved to appropriate forums.
stream staff
Stream Host
Posts: 45
Joined: Sat Oct 16, 2004 8:35 am
Location: uk
Contact:

Post by stream staff »

Don\'t trust these easy quick fixes and security through obscurity concepts. Its bad practice all the way around. Unfortunately many still see this as an ok thing to do and unfortunately many stream and content providers are not aware that their systems are completely open to the world. I cannot stress this enough so I will bold face, underline and cap it. DO NOT TRUST ANY SYSTEM THAT DOESN\'T HANDLE AUTHENTICATION AT THE ACTUAL SERVER!!!! It is a waste of your time, money and effort.
allthough i dont agree entirely with what you are saying jay i will offer you the chance to look at our authenticated shoutcast servers and see if you can find a way around it as i would be interested to see your results,

if you are interested please do drop me a note and i will add one to your account for you to play with for a month.

i look forward to your reply,,,,

Regards
Nick
User avatar
Jay
Will work for food (Administrator)
Posts: 3020
Joined: Mon Jan 14, 2002 12:48 am
Location: Next Door
Contact:

Post by Jay »

Well although I have not used all the current authentication services out there. This article was more aimed towards end users who are not willing or have no interest in relying on third party services. This type of service was kind of beyond the scope of this article as this is something not freely available for anyone to purchase or use without using your service. I as well as everyone would probably be curious to know exactly how your system works and why you did not just go with developing your own server or using an existing authentication system rather then modifying your network/systems to make shoutcast do it? In my opinion SHOUTcast is only good when you have the ability to list on their yp. The server itself has no value as many systems have and are being developed which are far superior. If you would prefer to not discuss this in the open forums feel free to pm me and I will be glad to give you an assessment of how secure I feel your system is. I am really not in the business of hacking around to figure out ways around obscure systems however I am sure there are those that are.
- Jay
stream staff
Stream Host
Posts: 45
Joined: Sat Oct 16, 2004 8:35 am
Location: uk
Contact:

Post by stream staff »

I think any comments about 'feelings' on the matter would not be best until either you have found an issue with it, or at least tried it in some way. Anecdotal comments do not serve the community well, as can be seen with the Shoutcast Forums, where rumour/conjecture and down right BS cause issues where none should arise.

We would like you to try it before making comment, as without that, the comments are worthless to the community and do not progress anything.

Regarding your comments as to why we produced such a product. This was down to demand, we now have over 60 clients using it, and their main point is that they do not want to use Icecast.

When we first launched the authentication on Shoutcast, Icecast nor Steamcast were robust enough for deployment in this area which therefore dictated that path.

We do realise a lot of people within the Shoutcast environment are very 'upset' that it is only available on our servers, however we do run a business so ultimately if we have developed the resources there is a price to use them.

With the above in mind, we will not be sharing how we technically do it as this would potentially remove any business we have in the Shoutcast streaming environment where as it has become a popular product.

It is an open offer to try it, but we do get the impression you wont be looking at it, which is a shame.

Nick.
User avatar
Jay
Will work for food (Administrator)
Posts: 3020
Joined: Mon Jan 14, 2002 12:48 am
Location: Next Door
Contact:

Post by Jay »

Well as I said you are taking this article to a different context and I am sorry you feel that I am somehow pushing your service offering aside by making the assertion that rigging a product to do something it was not designed to do is inherently bad. I am not saying that your service is inferior. In all honesty I do not know anything about your authentication product therefore I cannot make any assessment. What I do take issue with is ignorance about how things are designed to work and people who believe that by making a login page at a website that provide an open link to a SHOUTcast server somehow protects them. When you know as well as I do that this isn't true.

I have tried many of the freely available hacks to do this to SHOUTcast and honestly all of them have a flaw. So I do speak from experience not from 'feelings'.

You also misunderstood my question, I know that demand for authentication is high. That answer is obvious. My question was why would you be using or claim to be using a SHOUTcast server for the backend of this system? The shoutcast server is really not designed for this nor is it neccessary to use such a server to do this. It provides no value to the service other then maybe the name. As far as people being upset in the shoutcast community over your decision to keep this to yourself, I say great. I personally applaude you for keeping it under wraps. I think what users in the SHOUTcast community are really frustrated about is the promises made and not kept on the part of AOL/Nullsoft to continue the growth of that product. Service offerings like yours and alternative systems available only serve to make that fact glaringly clear.

For clarification I am not making any opinion on your service so please do not read otherwise. I do not think that it would serve you nor I very well to have me try to hack your server. I personally do not have the time. I understand your feelings about keeping your stradegies and product logic under lock and key but please understand my position to not want to subject myself to hacking your system.
- Jay
stream staff
Stream Host
Posts: 45
Joined: Sat Oct 16, 2004 8:35 am
Location: uk
Contact:

Post by stream staff »

Well its good to get into a little discussion with you about it and as it stands the offer of a trial is there for whenever you have the time and enthusiasm to play with such toys not so much breaking but just giving it a go......

Regards Nick
Post Reply