How do I log in?

After payment has been completed and validated, an email will be dispatched to the email address associated with your payment account.

Please note the following:

1. Login.page:
• OnDemand
• Your username will be the email address that is linked to your payment account
• Your password will be the #Trans.ID, which will be included in the confirmation email from paypal
2. If you are unable to login after payment and account validation, please don't panic!
• Your account is automatically created after payment confirmation. The approval happens after that, and also after passing through a few user eligibility validations.
• What are User Eligibility Validations?
• User eligibility validations were designed to detect and refuse registration attempts from users with unscrupulous intentions.
• If we detect that a request originated from a profile such as this, payment is refunded immediately, and the registration attempt denied.

For monthly subscribers (not OnDemand):

In the space provided for Host List, specify the comma seperated list of hostnames(fqdns) you wish to grant access to your encrypted scripts. Note, the hostname(s) provided during encryption will be only hosts on which the encrypted script(s) can be run. The script(s) will not function on any other host!

For monthly subscribers (not OnDemand):

In the space provided, specify when you wish for your script to expire.

Examples:

• 7d = 7 Days
• 2w = 2 Weeks
• 4mo = 4 Months
• 7000d = 19+ Years
• July-18-2022_15:00 = Specific date

If no option is selected, the default option will be "off". Which means your script will not expire!

In the space provided for Function names, specify the comma seperated list of functions you wish to protect, if using RStudio/Rconsole.

Choose 'no' (recommended) to disable the ability to debug your encrypted script

This setting forces your protected script to validate itself with our servers before allowing users to run it.

• NOTE: If an attempt is made to run a satelite enabled obfuscated script on a host without internet connectivity, the script will abort.

There are many different types of security settings that can be applied to an obfuscated code.

The question is; who needs that?

• Those who wish to retain as much control as is possible of all critical scripts

• Those who wish to prevent unauthorized modification attempts to their published code

Why would anyone need tight control of their scripts?

• For security related reasons of course - that's obvious enough, right?
• Security through obfuscation?
• Absolutely!
• But they said 'security through obfuscation' should not be considered security - how do you reconcile that?
• 'They' said a lot of things...most of them factually incorrect
1. 'They' said there's no way to prevent unauthorized modifications to your code once it is in someone else's possession
• The assumption being, if the user is on a system he has full admin rights on, he can do whatever he pleases.
2. They said (and some of them actually believe) that an obfuscated script is only marginally (if at all) safer than its plain text version.
1. The assumption here also is that any obfuscation (that anyone comes up with) is confined only to the scrambling of a few variables or text.
• That is a bad, woefully reckless assumption!
• Depending on the level of security desired by the script author, settings on an obfuscated script can involve:
1. Enforced online sourcing of an obfuscated code
2. Online sourcing authorization only for a select list of IPs
3. Restrictions of hosts on which an obfuscated code can be executed
4. Restrictions of user accounts permitted to run obfuscated scripts
5. Prevent executions initiated through certain programs, utilities...
6. Allow the executions of code only in specific time periods...
7. ..... the list goes on...really!
• Suffice it to say that the worst move a hacker can make (if they get in your system), is to blindly run an obfuscated code authored by us.
• Because, whenever that script fails to run, we will NOT provide detailed reasons. We just gently alert the proper contacts.
• Everything that they said was impossible, we made possible. We proved them wrong.
• Remember to always ask yourself these simple questions:
• Is a castle with doors and windows more secure than a castle without?
• Are your treasures more secure when protected and disguised through elements of the environment, or are they better left out in the open?
• Monitoring & Analysis of Metrics
• Periods of Executions, Users, Hosts/IPs
• Know the different periods during which your scripts are being executed, from where, and by whom
• This feature becomes all the more crucial, when the scripts being obfuscated contain sensitive credentials
• If you need to hardcode passwords or api keys in a script, you will want to ensure you keep tabs on where your scripts are located and who is running them
• We come from a deep SRE background of 20+ years - thus, for us, observability is paramount to adequate code protection
• How does secure imports work?
• There are different types of import security...
• The particular one equipped with all OnDemand scripts is known as online sourcing...
• It means, each time your script is executed, an attempt must be made to remotely source an important component of that script, through our web services, otherwise the execution is aborted
• Yes, this means you can monitor how often your scripts are being sourced...and also obtain other publically available basic information about the source requestor.
• This is yet another opportunity to not only detect the whereabouts of your code, but to also build a unique profile for unidentifiable requestors
• Some users may be unidentifiable for legitimate reasons, but generally, most users who take repeated steps to conceal their identity are usually doing it for rapscallion reasons
• Online Sourcing - Requires a centralized privately reachable web service (note, for OnDemand scripts, we provide that web service)
• Obfuscated scripts that are considered highly sensitive and confidential, will need to remotely validate themselves through this service.
• Validation means that the usages (or executions) of your obfuscated scripts will only be authorized IF and only IF specific conditions can be confirmed
• If the preset conditions are not met, the user will be denied access to the services provided by your obfuscated code. And yes, all denials will be logged.
• With this option enabled, you now have the ability to answer previously unthinkable questions:
1. Who is using my code?
2. Where has my code been used?
3. How often is my code being used?
4. Has anyone attempted to hack my script?
5. Are there any attempts to bypass the expiration dates of my scripts?
6. Why am i seeing these strange usage patterns from UserH? Is it a problem with my code?
7. Hmmm...why am I not seeing any activity from UserA?... He bought it but hasn't used it...hmmm
• When a user purchases an online-sourced obfuscated script from you, you should expect to see usage metrics from that user
• Lack of metrics could be the first indicator that a user is attempting to prod your script for vulnerabilities
• In that case, you can immediately, as an extra precaution, change all passwords or api keys that may have been hardcoded in that script