Subscription Software

Dear friends,

I want to sell software on a subscription basis. My client will pay a monthly fee to have access (via a password) to the software.

What I don’t know is how to impede access of a second, or more users to the software simultaneously with the same password.

Is there any literature on this sort of thing? I would appreciate any help.

Thanks - Peter

That’s one of the drawbacks to web apps. Restricting access is hard because you want legitimate users to get in while restricting the other type.

A couple of things you can do:
• You can’t allow the user to log in more than once
• Restrict by IP (awful way to do this because IP addresses change all the time)
• Two step verification. They log in, and then get a text message on their phone with a PIN.

Other than that, I’m not aware of much else you can do. In our web apps we log when people log in/out, their IP address, web browser, etc so that if we suspect any shenanigans we can restrict the login. But it’s hard to automate this type of security. I’ll be curious what other ideas people have.

I log people in/out like Bob does, and I check to see if that user is already logged in and then present a message to them that they are already logged in…If they are allowed to log in say into two sessions, then I count the number of sessions they have going and handle appropriately…it’s not full-proof but works pretty good…

Bob, thanks.

When you say:
“You can’t allow the user to log in more than once”
How do you do that, or how do I know he is logged in?

When their login is completed, I put a property in the Session object. Each user has their own session and the application object can iterate though the Sessions. Check to see if another sessions has the same userid or not.

If the user refreshes or switches browsers it’s possible that they may actually have multiple logins. So I usually check the IP address as well (and log and keep that as a property in the Session too).

Very similar to what Bob mention above; except I am a bit more cruel and boot out the previous session for the new session to take it place.

I have a method to check if user has a previous open session

[code]
dim loopCount as Integer

for loopCount = 0 to (app.SessionCount - 1)
if app.SessionAtIndex(loopCount).userName = userNameSearch then
remoteIPAddress = app.SessionAtIndex(loopCount).RemoteAddress
app.SessionAtIndex(loopCount).logout
return true

end if

next

return false[/code]

How do you handle people having more than one computer? I use the forum here from my iPad, MacBook Pro, iMac, and I switch between them all the time. So one login only might be a bit low.

Excuse me…
But don’t you speak about different things!?

Markus write about entering a forum, this forum. The OP ask about subscription software.

In my eyes, it will be a stand alone application running from a device and to use it you will need to be a subscriber. Such as Xojo, but also Adobes software works like this (I assume…).

For me, in my eyes, I see no problem.
IP may differ from home, work, train, relatives and and other places people may connect to Internet… McDonald’s! :slight_smile:

The MAC address of the device may give some help.
I’m not so sure about session… but since the pro’s suggest sessions I can live with that! :slight_smile:

For me, I’ve created a secret key that goes along with the userID or, rather the e-mail in my case… This key, “disposable serial keys”, is generated in the application and then encoded on the server side to assure connections is made from “my” application and not just any other application.

Well… with such software as described in another thread, it’s easy to look inside the compiled code to see the structure and then, make a working key. I’m aware of that. For me, it’s fine. Along with other ideas, it’s more or less bullet proof.


It really all depends on the end users.
The “hackability”! :slight_smile: How potential is your SW likely to be illegally used?

For you, in your case, I would think of something else. Maybe a 24 hrs key, or week key?
After a while, I would think of a working solution also for your case. I truly doubt there are any books out there to describe these things… It’s my impression.

Whatever you may choose, I think ONE thing will not solve it all. Look for many things and then a combination of these.
The pro’s may look at this in different way than me, they always tend to do! :slight_smile:

I wish you luck!

(PS. On server side I work with Access and Classic ASP, but all can easily be migrated / upgraded to SQL Server and dotnet. I will do, eventually.)

I don’t have all answers, but I hope it helps in the future development. To open the door to new ideas.

For you, I’ve thought of a solution that might work and that can be fairly safe and not generate too much work for either you and the user. It is similar to the current solution as I’m building.

Let’s say, you will limit the users access to at most 10 MAC addresses for a 30 day period. That should cover most users need, on different devices and in different situations.

Save each MAC address with the userID, when log in to the service.

When a MAC address is not used for more than 30 days, then DELETE this post.


Then it happens, every now and then, one user has a software generated MAC address generator that will generate a unique MAC address each time the user connect to your service. Then, there will be maybe 10 MAC’s a day! (Or so, very much.)

If so, then you can either exclude this user from the common path and let this specific user have unlimited access to your service. You can also automate this process with a confirm email send to this user each month. To verify the user.

OK. ?? You are with!?
Out of the hacker-persepctive, an evil person will need to aim at this specific user, to be one of the many MAC’s in the log. It will work. But then, after 30 days, each month, a new serial key will be needed and then the evil user will no longer be able to use the service.

Of-course, such system will not eliminate the free users to nothing, but it will make it much more difficult.


Let’s say, one person is sharing the secret key, each month, with his friend. How long time do you think this person will bother to send the new key to his not paying friend…? Maybe one or two times!? I would say, it’s work the effort, from your side. It’s not that bad…!


When it comes to IP’s me myself would avoid using it in today’s era of free internet access. I can imagine a company with different IP’s all over. One floor, one office, one IP, second floor or building, second office and a second IP. Then, in the cafeteria… a third IP and so on! The same or different IP each time. For you, to depend on such solution would … be demanding!

But really, to combine these two ideas would also limit the work for you and the user.

Let’s say one user has dynamic MAC addresses, but at the same time always connect from only two or three IP’s. Home and office.

So… if the dynamic MAC is generated from the same IP or IP range, then it’s also not a problem.


So… a combination of these things will work! Just remember, the work for all of this, both for you and the client must remain at absolutely minimum. There are computers … and they do all the boring work with no complain! :slight_smile:

All is different – nothing is wrong! :slight_smile:


EDIT
Feel free to edit all the numbers as I write. 30 days may be 20 days… 10 MAC’s may be 20 or 5. I open the door to free thinking! You do the tuning, to suit your needs in your specific situation, with your users! :slight_smile:

Another thing to consider is the load you will put on the server for the additional sessions.

this would not prevent the same user from the same machine spawning 30 tabs and logging into the site.

[quote=165831:@Rich Hatfield]Another thing to consider is the load you will put on the server for the additional sessions.

this would not prevent the same user from the same machine spawning 30 tabs and logging into the site.[/quote]

Each tab will start a new session, but if the access control makes sure an IP addresses can be in limited numbers, not all his tabs will see the app.

Thanks to all the suggestions. Will try to digest all the info and see what I can do. - Peter