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 from you, such that you understand the process. Look at the following screenshot.
The above is the "CRUD Generator" from Aista Magic Cloud. It allows you to select your database, and click "CRUDify all tables", at which 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.
The above are the default authorisation requirements for invoking your CRUD verbs, and 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.
The above screenshot shows you how you can edit the list of roles legally allowed to invoke your individual endpoints and verbs. 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.
In addition to creating authentication and authorisation requirements for individual 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". In fact, to open up for additional roles to invoke your endpoints you explicitly need to change the configuration for the 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", any schmuck with a rainbow dictionary database can brute force your password in 2 seconds, at which 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.
Latest comments (0)