Security considerations in 8th

Data-security is a hot topic, and has many facets. The design of 8th attempts to take as many of them into account as possible — primarily because the initial impetus for designing 8th was to write a secure “note-pad” application.

8th helps secure your application by focusing on these major issues:

  • data corruption
  • IP disclosure
  • reducing the attack surface
  • discouraging unsafe coding

The issues of “data corruption” and “IP disclosure” are linked in our methodology. When an 8th application is created using the “build” process, the application’s sources and resources are encrypted using a tamper-evident method (AES-256-GCM). What that means in practice is that if any corruption of that application’s deployed data (e.g. the “installed application package”) occurs, it is detected and no execution of the corrupted data will occur. It is immaterial whether the corruption was accidental or due to hacking. Note: encrypted applications are only available in “Professional” and “Enterprise” editions.

In addition, the application is signed using RSA, and the encrypted application is verified to have the correct signature on launch. Thus, even if the application package is decrypted, a falsified version of the application cannot be created and run.

Similarly, because the application data are encrypted, they are resistant to reverse-engineering or data disclosure. It is not possible to achieve 100% un-hackable encryption without hardware or trusted third-party server support, so we do not claim that. However, we do claim that reverse-engineering or decompiling your application, if built using the Professional or Enterprise version of our product and selecting “encrypted” binary, is very difficult and unlikely to be cost-effective for an attacker.

Another aspect of data-security is “reducing the attack surface”. There have been many attacks based on substituting or interfering with an application’s use of external libraries. Still others have been based on the use of out-of-date libraries on certain platforms. The 8th engine statically incorporates the sensitive libraries it requires, so that there is no dependency on the platform, the library cannot be replaced, and the attack-surface is reduced considerably. As new vulnerabilities in libraries used by 8th are found, updated versions are used and incorporated into each new release — you therefore benefit immediately.

Further reducing the attack surface, 8th does not give the programmer unfettered access to memory. Any 8th data structures exposed to the programmer are bounds-checked so that attacks such as “stack smashing” aren’t possible.

Because 8th makes it very easy for your application to interpret text and run it as code, you as a developer need to be careful to only permit such interpretation (e.g. via eval) from trusted sources. 8th has a mechanism to reduce this attack surface as well: you can designate a “name-space” as the “only” one available, and restrict the words exposed there. Similarly, there are special data-conversion words to take a JSON string and safely interpret it (rather than using eval). 8th makes it easy for the developer to write safe code, and while it does permit accessing external libraries (where it thereby loses control), it encourages software authors to use the built-in, safe alternatives.

With 8th, your data’s security is in your hands!