Synopse Open Source

After having enjoyed EKON 21 conferences in Köln, some quick post to share material about my presentations. MicroServices: SOLID Meets SOA MicroServices: Event-Driven Design Practical Domain-Driven Design I also included the "Practical DDD" source code in a new sample folder of the mORMot  […]

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

They can be used for:

• Authentication: including a JWT to any HTTP request allows Single Sign On user validation across different domains;
• Secure Information Exchange: a small amount of data can be stored in the JWT payload, and is digitally signed to ensure its provenance and integrity.

See http://jwt.io for an introduction to JSON Web Tokens.

Our mORMot framework now implements JWT:

• HS256 (HMAC-SHA256) and ES256 (256-bit ECDSA) algorithms (with the addition of the "none" weak algo);
• Validates all claims (validation dates, audiences, JWT ID);
• Thread-safe and high performance (2 µs for a HS256 verification under x64), with optional in-memory cache if needed (e.g. for slower ES256);
• Stand-alone and cross-platform code (no external dll, works with Delphi or FPC);
• Enhanced security and strong design - per instance, it is by design immune from https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries
• Full integration with the framework.

In order to follow best practice, our .private key files are always protected by a password.  A random value with enough length and entropy is always proposed by the ECC tool when a key pair is generated, and could be used directly.
It is always preferred to trust a computer to create true randomness (and SynCrypto.pas's secure TAESPRNG was designed to be the best possible seed, using hardware entropy if available), than using our human brain, which could be defeated by dictionary-based password attacks.
Brute force cracking would be almost impossible, since PBKDF2_HMAC_SHA256 Password-Based Key Derivation Function with 60,000 rounds is used, so rainbow tables (i.e. pre-computed passwords list) will be inoperative, and each password trial would take more time than with a regular Key Derivation Function.

The issue with strong passwords is that they are difficult to remember. If you use not pure random passwords, but some easier to remember values with good entropy, you may try some tools like https://xkpasswd.net/s which returns values like $$19*wrong*DRIVE*read*61$$.
But even then, you will be able to remember only a dozen of such passwords. In a typical public key infrastructure, you may create hundredths of keys, so remembering all passwords is no option for an average human being as (you and) me.

At the end, you end up with using a tool to store all your passwords (last trend is to use an online service with browser integration), or - admit it - store them in an Excel document protected by a password. Most IT people - and even security specialists - end with using such a mean of storage, just because they need it.
The weaknesses of such solutions can be listed:

• How could we trust closed source software and third-party online services?
• Even open source like http://keepass.info/help/base/security.html may appear weak (no PBKDF, no AFSplit, managed C#, SHA as PRNG);
• The storage is as safe as the "master password" is safe;
• If the "master password" is compromised, all your passwords are published;
• You need to know the master password to add a new item to the store.

The ECC tool is able to work in "cheat mode", storing all .private key files generated passwords in an associated .cheat local file, encrypted using a cheat.public key.

As a result:

• Each key pair will have its own associated .cheat file, so you only unleash one key at a time;
• The .cheat file content is meaningless without the cheat.private key and its master password, so you can manage and store them together with your .private files;
• Only the cheat.public key is needed when creating a key pair, so you won't leak your master password, and even could generate keys in an automated way, on a distant server;
• The cheat.private key will be safely stored in a separated place, only needed when you need to recover a password;
• It uses strong File Encryption, with proven PBKDF, AFSplit, AES-PRNG, and ECDH/ECIES algorithms.

There are still a few days for "very early birds" offer for EKON 20 conference, and meet us for 3 sessions (including a half-day training/introduction to mORMot)! Join us the 7-9th of November in Düsseldorf! Our sessions are not restricted to mORMot, but will use mORMot to illustrate some  […]

You should have noticed that Delphi 10.1 Berlin has been released. Our Open Source projects, including mORMot and SynPDF and their associated documentation have been updated to support this new revision. Any additional feedback is welcome, as usual!

We have seen previously how the ORM part of the framework is able to provide an Audit Trail for change tracking.
It is a very convenient way of storing the change of state of the data.

On the other side, in any modern SOA solution, data is not at the center any more, but services.
Sometimes, the data is not stored within your server, but in a third-party Service-Oriented Architecture (SOA).
Being able to monitor the service execution of the whole system becomes sooner or later mandatory.

Our framework allows to create an Audit Trail of any incoming or outgoing service operation, in a secure, efficient and automated way.

If you compare with existing client/server SOA solutions (in Delphi, Java, C# or even in Go or other frameworks), mORMot's interface-based callback mechanism sounds pretty unique and easy to work with.

Most Events Oriented solutions do use a set of dedicated messages to propagate the events, with a centralized Message Bus (like MSMQ or JMS), or a P2P/decentralized approach (see e.g. ZeroMQ or NanoMsg). In practice, you are expected to define one class per message, the class fields being the message values. You would define e.g. one class to notify a successful process, and another class to notify an error. SOA services would eventually tend to be defined by a huge number of individual classes, with the temptation of re-using existing classes in several contexts.

Our interface-based approach allows to gather all events:

• In a single interface type per notification, i.e. probably per service operation;
• With one method per event;
• Using method parameters defining the event values.

Since asynchronous notifications are needed most of the time, method parameters would be one-way, i.e. defined only as const - in such case, an evolved algorithm would transparently gather those outgoing messages, to enhance scalability when processing such asynchronous events. Blocking request may also be defined as var/out, as we will see below, inWorkflow adaptation.

Behind the scene, the framework would still transmit raw messages over IP sockets (currently over a WebSockets connection), like other systems, but events notification would benefit from using interfaces, on both server and client sides.
We will now see how...

Illustrated Spare Parts Catalog is, as its name suggests, a software for creating and publishing spare parts catalogs. It uses mORMot for client-server communication and ORM, and SynPdf for the reporting. Sounds like a powerful solution. It is also a testimony that you could use big databases (20 GB  […]

We just noticed a nice feedback from a mORMot user. Vojko Cendak commented the well-known DataSnap analysis based on Speed & Stability tests blog article written by Roberto some months years (!) ago. It is not meant to be the final word, perhaps there was some tuning possible for RTC (which is  […]