SR3 Decking Question, Creating System Accounts Options

[Drraagh]

I don't know how many deckers are out there, but perhaps this trick might be valuable to them if it works. I came up with this when I was sleep deprived, and though the logic works on it in my opinion, I wanted to get some clearer heads to consider it as well.

With SR3 Matrix, there's the Validate Account command which allows you to make any sort of an account. Then you roll 1D6 times the number of successes to get how long the account stays active under normal conditions.

What that means is you have an account for let's say 3 days. Then you have to crack a new account when that one expires. So, what we might want is for an account to create itself after this one is deleted, but not right away. We want maybe a few hours. So, can we do this?

Write a program/command set/IC Construct that watches for the invalidation of accounts or regularly (every day at a specific, or even better, a random time) checks the password list to see if the account still exists and if not, create a new account or at least attempt to.

Looking at the example of Command Sets, a decker could, in essense, set up a simple script to each week create a superuser account and email him with login info and then make a comcall to a beeper or cloned cellphone or some sort of notification telling them an account was set up.

Then, if the decker wants added security, the can re-add the command set, sincethey are one time batch jobs, but are there other ways to do that process? Especially ones that are dependant on the first account being deleted. Like, if the invalidate account was used, have the program wait an hour before it runs to reset up the account.

I do know that what I've proposed while somewhat of a 'cheat' to the system is in essence what a decker would look at doing, at least in my mind. They would, if they plan to use the system again, prefer a backdoor that'll stick. And, with the rules, you could have a system admin find the program/script and delete it and leave the decker out in the cold.

For example, you are stealing programming time on their system, you don't want to always have to create a new account, and more importantly, and not covered by my scripts, is that unless you backup your work regularly, they may have just invalidated all that work when they deleted the account and its storage space.

[mfb]

i did that with Angel Satcom, except that since it was an admin account, i just had the script create a new account every few days--no roll required. given how easy it is for security deckers to find command sets, though, i think the GM is within his rights to kill the command set after a week or so, depending on the circumstances.

another potential weak spot is the fact that you have to have the account information for the new accounts the script creates. you can have it email them to you, but that can be traced; a better way would be to have the script generate the account information with a specific algorithm, keyed to the date. you can then figure out what the current account information is by plugging the date into that same algorithm.

[Westiex]

In which case they just wait to see what account the command script creates, waits for the new account to log on, then sics the black IC on the decker.