Session security must not rely on SessionIDs, bizare URLs, secure cookies, secret tokens, magic keys or any other piece of information that can be guessed or stolen during transmission.

Capture and re-transmission of encrypted messages must be pointless.

The framework must protect transparently against brute-force and authenticated sessions abuse.

The framework must handle transparently input serialization to harmless/built-in only object types.

The framework must not depend on strict/pre-defined configuration style/format and/or directory structure.

The framework must not tie to a particular storage or UI technology.

The framework must provide the facilities for easy testing/debugging and profiling.

The framework must not rely on components that inhibit elastic/horizontal scalability.

The framework must work seamessly in multi-thread/multi-process or event-driven environments.

A lot of discussions happens around “JavaScript criptography considered harmfull” so a bit of clarification is needed to understand why and how Fanery use it:

HTTPS cannot be replaced by JavaScript criptography, however SSL/TLS is no help against the majority of common attacks, that’s why Fanery use “scrypt + NaCl + One-Time Pad” (both server and client side) to achieve protection against many of those threats using JavaScript criptography together with HTTPS and not as a replacement.