Aista – Magic Cloud – Generate a CRUD app in seconds

Categories
API Hyperlambda

How Hyperlambda automagically secures your Web API

The energy required to brute force Magic’s JWT tokens is the same amount of energy we need to boil all the water that exists in the galaxy

How Hyperlambda automagically secures your Web API – Aista

Some people have expressed doubts in Hyperlambda’s integrated security model. It seems to be difficult to believe that Hyperlambda automagically secures its API. This is a misunderstanding of how the CRUD API generator works. I will therefor explain how Hyperlambda automagically secures your Web API, with zero effort, such that you understand the process. Look at the following screenshot.

Magic's CRUD API generator

The above is the “CRUD Generator” from Aista Magic Cloud. It allows you to select your database, and click “CRUDify all tables”. At this point Magic will automagically generate a CRUD Web API wrapping all tables in your database. Each Hyperlambda endpoint file will by default require the user to be authenticated and authorised to invoke the endpoint. The internal mechanism Magic is using for this is JWT. No JWT token, no invocation.

Magic also allows you to declare what roles are allowed to invoke the endpoint. You can set default values for all endpoints generated by clicking the “Set defaults” button. Below is a screenshot illustrating the process.

Changing default authorisation requirements for the CRUD API generator

How Hyperlambda automagically secures your Web API – Aista

The above are the default authorisation requirements for invoking your CRUD verbs. This is automagically applied to all your database tables if you click “Apply”. However, you can also edit individual tables and CRUD verbs, and override the role requirements on a per table and per verb basis. Below is a screenshot illustrating the process.

Applying reCAPTCHA and authorisation requirements for individual CRUD API endpoints and HTTP verbs

The above screenshot shows you how you can edit the list of roles legally allowed to invoke your individual endpoints. If you want to have the “Read” endpoints publicly available, you can simply delete the content of your “Read” textbox. And the endpoint is publicly available for everyone to invoke. If you want to allow for users belonging to the role of “superuser” to be allowed to invoke the POST endpoint, you set the value of the “Create” textbox to superuser, etc.

How Hyperlambda automagically secures your Web API – Aista

In addition to creating authentication and authorisation requirements for endpoints, Magic also allows you to demand reCAPTCHA values for invocations. This is useful if you want to prevent bots to invoke your endpoints. If you’ve got script hackers creating Postman scripts invoking your endpoints for instance, you can easily eliminate this problem by registering a reCAPTCHA 3 account with Google, apply configuration settings, and set the value of your reCAPTCHA endpoints to for instance “0.5”.

By default Magic will only expose endpoints you generate to the roles of “root” and “admin”. Actually, to open up for additional roles to invoke your endpoints you need to change the configuration for CRUD generator. If you don’t, nobody not authenticated and authorised to invoking your endpoints can invoke your endpoints.

Of course, there are no 100% perfect guarantees in security. If you choose a root password of “admin”, anyone with a rainbow dictionary can brute force your password easily. At this point he’s authenticated as a root user, and are allowed to invoke every single endpoint in your Magic cloudlet. However, if you create a complex password, and protect it as you should, there are no known methods to invoke a Magic endpoint for users that are not authorised to invoking them.

Magic’s internal security measures

Magic is using BlowFish with individual per record based salts to securely store your passwords in its user database. In addition, it generates a JWT secret between 80 and 150 characters in length during setup. It also salts the CSRNG before it uses it, with entropy given by the parent cloudlet, which first of all adds to the existing salt of the internal BouncyCastle CSRNG component, in addition to ensuring the entropy of generated CSRNG values explodes in complexity. If this isn’t good enough for you, you can even manually edit the JWT secret to manually add complexity to it if you wish.

According to conventional knowledge about cryptography and security, the above implies that the energy required to brute force guess the JWT token becomes the same amount of energy we need to boil all the water that exists in the galaxy.

Even with the best super computers we have today, this would require a million-trillion years or something. I don’t mean to be rude here, but believe me when I say that Magic is secure by default. Sure, we might have done something wrong, accidentally created a security hole, but we’re obsessed with security at Aista, and we constantly check our own codebase for security holes, ensuring we keep components updated to avoid holes, and the entire platform is open source, allowing others to help us here. If you don’t believe us, you can register your own personal cloudlet and create your own CRUD APIs below, and verify that what we’re saying here is actually true.