HexaEight Sessions - Frequently Asked Questions

What are HexaEight Sessions?

HexaEight Sessions are JSON Web Tokens encrypted with a dual password combination that can only be decrypted by the person who created the Token by entering the correct password. A Sample HexaEight Session can be inspected HERE.  

What Are The Contents ?

HexaEight Sessions contain keys for communication with HexaEight Token Servers. In order to prevent attacks, every HexaEight session is protected by the password which is known only to the user.

How Is HexaEight Sessions Different From Other Authenticated Sessions?

Session security is crucial when building applications that involve user sessions. However, most user sessions are vulnerable to attacks because they expose tokens within the session. It can also be difficult to detect stolen tokens, which poses a challenge for developers and security professionals. Many user sessions rely on the trustworthiness of the external environment to secure user sessions and protect the long-lived token.

Unlike traditional user sessions, HexaEight Sessions do not have the concept of long-lived tokens or refresh tokens, because this functionality is already built in through authenticated encryption. As a result, HexaEight Sessions are not vulnerable to stolen keys or tokens.

HexaEight sessions can be used to replace user sessions in various contexts, such as web applications, desktop applications, and login sessions on Unix, Mac, and Windows systems.

How Does HexaEight Session Tie to into an Application?

A Client ID, issued by the HexaEight Token server, is used to bind HexaEight Sessions to an Application Realm. To communicate with resource servers, the HexaEight session must retrieve the shared key of the destination resource in order to establish a secure communication.

Does HexaEight Sessions support Authorization?

HexaEight Token Server Implements the authorization required for HexaEight Sessions using customized ABAC CASBIN Model and Policy files.  HexaEight Sessions are only permitted to fetch shared keys for approved destination users or resources based on the authorization policies.

What are Asymmetric Shared Keys used in HexaEight Sessions?

Every HexaEight session requires a key belonging to the destination to create a virtual secure communication channel for encrypting and decrypting messages. This key is called an Asymmetric Shared Key and is issued by the HexaEight Token Server. Asymmetric Shared Keys issued by the Token Server for HexaEight sessions created inside Applications are called Client Tokens, while Asymmetric Shared Keys issued for machine-to-machine (M2M) communication are called Machine Tokens.

What happens if an Asymmetric Shared Key is stolen in transit?

Nothing, A compromised Asymmetric Shared Key is useless to an attacker because encryption and decryption require a password, which should be used in combination with this key. Since the end user owns this password, an attacker cannot compromise a HexaEight session by simply obtaining an Asymmetric Shared Key because the user's password is not stored anywhere, neither locally nor on HexaEight servers, and is known only to the user. If the user suspects unusual activity, the resource login token that was used to create the session can be revoked and a new HexaEight Session can be created by generating a new resource login token, allowing the user to stay one step ahead of the attacker in protecting their session.

How Does HexaEight Session Communicate With Other Application Realms?

Client Applications can be designed to have several HexaEight Sessions with access to various Application Realms. This is especially handy when third-party client apps require access to resources or need to communicate with users in a different Application Realm.  HexaEight Sessions include a self message protection feature that allows protecting messages when communicating with another HexaEight Session belonging to the same user inside the same Client application to prevent attacks aimed at sessions while communicating locally

How Do End Users Login To HexaEight Sessions?

To create a HexaEight Session in a Client Application, end users must first download the HexaEight Authenticator Mobile App (available for free on Android and iOS), register their email address, and generate an Email Digital Identity token. During the session creation process, they will be presented with a QR code, which they can scan using the HexaEight Authenticator app to create their HexaEight Session. After the session has been created, end users can log in to their HexaEight User Session 

Do HexaEight Sessions require a Library for Integration?

HexaEight Sessions is currently available for use with .NET languages. This allows for cross-platform application development for Windows, Mac, and Unix systems. HexaEight Sessions is also compatible with web assembly technologies, such as Blazor Apps, enabling it to be used for powering both web and mobile applications directly from a browser

What languages are supported by HexaEight Sessions

HexaEight Sessions can be implemented in applications written in any .NET language, such as C#, Visual Basic, F#, WiX, and C++. It can be accessed through the NUGET Platform and our library is also being ported for use with other major programming languages. This allows developers to integrate HexaEight Sessions into a wide range of applications, systems and devices.

How do I integrate HexaEight Session In Applications?

How can I send a secret message via Email so that it cannot be intercepted by the EMail Provider?

Click HERE To View the Enlarged Screen Shot of Alice encrypting the Message to Bob
Click HERE To View the Enlarged Screen Shot of BOB decrypting the Message received from Alice

The Command line Program showcased in this use case was developed by integrating HexaEight Sessions.

Additional Questions?

If you have more questions feel free to Contact Us and we will be happy to help you.

Privacy Policy

Terms of Use

© Copyright 2023 HexaEight - All Rights Reserved
HexaEight Trademark is held by HexaEight. Various trademarks are held by their respective owners.