Authentication as a licensing mechanism
All software developers want to eat and it is very disappointing when a program that has spent a lot of time and effort is available for use to anyone without legal fees in favor of the author. The developer, not getting his hard earned money, begins to worry, sleep badly, or even completely stops creating his products. They began to protect software from unauthorized use almost at the same time when they started selling software products. At different times, different mechanisms were used - serial numbers, binding to CDs and computer settings, the use of electronic keys. All these mechanisms are covered in sufficient detail on the Internet. And how to protect the interests of SaaS developers of information solutions is less. I’ll try to talk about one of the mechanisms for “licensing” online software,
To begin with, it is worth listing what we are still talking about. Conditionally, the problem can be divided into two parts:
• Illegal copying of software;
• Illegal use of software.
You can forget about illegal copying, if you distribute your software as a service. Yes, of course, unlike software distribution in the usual way, the program itself does not fall into the hands ofan attackeruser and so just can not copy it. However, you should not relax, since after gaining administrative access to your system, you can still copy the software. Do not forget that some SaaS solutions are written in scripting languages, which makes it easier for the attacker to modify and assign the results of the developer’s labor. To protect this area from attack, it is worth using strict authentication for administrative accounts, conducting an audit of access to the system and carefully choosing sites for hosting your service. Everything is pretty commonplace.
Protection against illegal use is also, at first glance, simpler. Unlike local hosting, the user does not have access to the executable software file, and as a result, cannot modify his code or otherwise disable his protection. That is, it is easier for us to ensure the integrity of our software and its protection mechanisms. Assuming that the program code does not contain errors, we can conclude that protecting SaaS from illegal use is reduced to providing a mechanism for authenticating the user. It should be noted that my assumption about the absence of errors, unfortunately, is only an assumption. Even in such critical systems as RBS systems, there are many software errors .
Now the most common protection mechanism is a banal login password issued to the user to access the system. What threats does this pose? If the user does not store any of his data in the system, he will not care about the safety of his password. In addition to the fact that the password can be intercepted or stolen, the user himself can pass it to his friends, workmates or publish it on the Internet. This begs the direct analogy with the serial number used to protect desktop software. The business model is most vulnerable when, for example, you sell access to the database for a certain period and the payment does not depend on the number of documents viewed. In this case, under a single login in the system can sit a whole team of "like-minded people." One of the methods of protection can be a mechanism for limiting sessions initiated under one login. The mechanism is quite effective, but not completely solves the problem.
Recently, I had to collaborate with several companies that decided to restrict access to their services in a more strict way. To ensure reliable “licensing”, tokens with non-retrievable keys were used, which in fact are analogs of software protection hardware keys. The Active Rootoken Web device produced by the Active company allows you to build an authentication scheme in such a way that you can’t use the service without physical ownership of the key. That is, one key - one user. This approach allows us to solve the problem of prohibiting the use of the service by many people under one license. This is how strong authentication has acquired for me an additional property of software licensing.
In more detail about the authentication mechanism of Rutoken Web I wrote here.
To begin with, it is worth listing what we are still talking about. Conditionally, the problem can be divided into two parts:
• Illegal copying of software;
• Illegal use of software.
You can forget about illegal copying, if you distribute your software as a service. Yes, of course, unlike software distribution in the usual way, the program itself does not fall into the hands of
Protection against illegal use is also, at first glance, simpler. Unlike local hosting, the user does not have access to the executable software file, and as a result, cannot modify his code or otherwise disable his protection. That is, it is easier for us to ensure the integrity of our software and its protection mechanisms. Assuming that the program code does not contain errors, we can conclude that protecting SaaS from illegal use is reduced to providing a mechanism for authenticating the user. It should be noted that my assumption about the absence of errors, unfortunately, is only an assumption. Even in such critical systems as RBS systems, there are many software errors .
Now the most common protection mechanism is a banal login password issued to the user to access the system. What threats does this pose? If the user does not store any of his data in the system, he will not care about the safety of his password. In addition to the fact that the password can be intercepted or stolen, the user himself can pass it to his friends, workmates or publish it on the Internet. This begs the direct analogy with the serial number used to protect desktop software. The business model is most vulnerable when, for example, you sell access to the database for a certain period and the payment does not depend on the number of documents viewed. In this case, under a single login in the system can sit a whole team of "like-minded people." One of the methods of protection can be a mechanism for limiting sessions initiated under one login. The mechanism is quite effective, but not completely solves the problem.
Recently, I had to collaborate with several companies that decided to restrict access to their services in a more strict way. To ensure reliable “licensing”, tokens with non-retrievable keys were used, which in fact are analogs of software protection hardware keys. The Active Rootoken Web device produced by the Active company allows you to build an authentication scheme in such a way that you can’t use the service without physical ownership of the key. That is, one key - one user. This approach allows us to solve the problem of prohibiting the use of the service by many people under one license. This is how strong authentication has acquired for me an additional property of software licensing.
In more detail about the authentication mechanism of Rutoken Web I wrote here.