## nKode is easier to remember and more secure than a password

### Create an nKode

1. Enter your email

#### 2. Set your nKode

Select 4 icons that will be your nKode. Icons can not be repeated.

Example: pizza, ladybug, wine, baseball

#### 3. Confirm your nKode

Confirm your nKode by reentering it.

#### 4. Login with nKode

Once you've confirmed, the login screen will open. Enter your nKode to login

### How nKode Works

#### Interface Settings

Your nKode interface is configurable. Under advanced settings, you can change the number of keys and the number of attributes per key. (from this point forward, this document will use the term attribute instead of icon)

#### Account Creation

The server is able to deduce your nKode from two entries. Notice how, in the set and confirm images below, no attribute in the set nKode interface share a key with any other attribute in the confirm. This is called an attribute dispersion.

#### Attribute Dispersion

The login interface looks different than the set and confirm interfaces. It has three more attributes per key. A dispersion is possible if the number of attributes per key is less than or equal to the total number of keys. Since the login interface has more attributes per key than keys, we call this a dispersion-resistant interface. If a malicious actor steals your interface, they can use your interface to phish for your nKode. If the login interface was dispersable, an attack might go like this:

1. You click a malicious link from your email or text saying you need to authorize USPS to send you a package (or whatever the latest scam is today).
2. You're redirected to a site with your nKode interface requesting authorization with your nKode.
3. You enter your nKode, but you're informed you entered the wrong nKode.
4. The attacker disperses your interface and requests you enter your nKode again.
5. You enter it again, and your nKode is stolen.

The greater the difference between the number of attributes per key and the number of keys, the greater the dispersion resistance, which comes with trade-offs. If there are too few keys, it becomes easier to randomly enter keys and accidentally get into your account without actually knowing your nKode. If you increase the number of keys without increasing the number of attributes per key, your interface becomes more dispersable. If you have too many attributes and keys, the interface is too busy, which makes it challenging to find your attributes.

#### Server-Side Attributes

A traditional password is composed of ASCII and sometimes Unicode characters. These are salted, hash, and stored in a database. nKode is similar. An unsigned 64-bit integer represents every attribute, though it can be a byte array of any size. These server-side attributes can be rotated daily, weekly, or any other cadence desired. Here's how it works:

1. An administrator or cron job starts the server-side attribute renewal.
2. The server-side attributes are rotated, and an intermediate transformation is applied to the user's server-side keys
3. Has a successful login, and the user's keys, salt, and hash are all replaced.

#### Login

Every time you log in, your attributes are randomly shuffled. Attributes don't move to arbitrary locations within the key; attributes are a part of a set. You can identify the set by its position within the key. In the example below, you can see some attributes haven't moved, some moved to other keys as a group, and some moved to different keys alone.

### FAQ

#### How does nKode defend against common attacks?

At the time of this writing, nKode is only a demo web application. Ideally, all nKode authentication is done through a mobile application. A mobile application can make nKode more secure by requiring passkeys and biometric authentication to get the nKode interface. This makes it very difficult to steal or use your nKode.

##### 1. MFA Prompt Bombing

Many MFA solutions try to make login as frictionless as possible. This kind of frictionless system makes prompt bombing a viable attack. Adding some friction to the login process, nKode mitigates prompt bombing, not so much that it's too time-consuming but not so little that a person could mindlessly accept an MFA request or accidentally fat-finger and accept an authentication request by mistake. The easiest attack vector for a nKode MFA bomb is session hijacking. Stealing nKode is more complex, making it an unlikely attack vector. nKode can mitigate this by adding a button, "I did not make this MFA request." The server can block fraudulent requests if the user presses this button. Otherwise, the user enters their nKode. Since a user has to look for their nKode, it prevents them from quickly typing in a passcode without thinking, giving them a chance to reconsider their decision.

##### 2. Service Desk Social Engineering: Scattered Spider

An nKode interface is made from any visual attribute. To make this more concrete, take a look at Flaticon. If every employee at the service desk has a randomly generated interface from abstract visual attributes like those found on Flaticon, an employee would have difficulty explaining their nKode. Moreover, this interface can be further protected with a 2FA keycard so only the employee can render their interface. For an attacker to get a target's nKode, they'd have to be with the target, and the targeted employee would have to point to the attributes on their screen since they're difficult to describe in words. The attacker must also steal the employee's 2FA keycard to render the login screen.

##### 3. Session Hijacking

To mitigate the damage from session hijacking, jwts or session tokens can be made read-only by default. When a user makes a sensitive write transaction, such as updating personal information or sending money, they must enter an nKode.

##### 3. Sim Swaps

If a user's device is damaged, lost, or stolen, they'll need a way to establish authentication keys with the new device without using the old device. We are building two types of nKode offerings:

1. Sign in with nKode is a B2C service nKode SSO is a B2B service.
2. The solutions below will use the terms customers and mobile carriers, but these are interchangeable with employee and service desk.

###### Temporary nKode Portal

The customer calls their mobile carrier to activate the sim for a new phone without the old device. The customer provides information like their name, dob, and ssn and answers security questions. The carrier will then activate a temporary web portal where the customer enters their nKode to authenticate the request. When the portal is activated, the customer with the authenticated phone will receive a notification on their nKode app alerting them to the activated portal. If the user has their device, they can close the portal by entering their nKode. The portal should only be opened if the user can't use their device to activate the new sim. If their phone is stolen, the thief can't stop this process if they don't know the user's nKode. Customers who want higher security can specify a wait period before a replacement device is activated. If the portal isn't closed before the end of this waiting period, the sim swap or new device enrollment can proceed.

###### Authentication nKode Delegates

This solution is only suitable for Sign in with nKode. After a user has installed the nKode app and created their account, they can delegate authentication to trusted friends and family who also have a Sign in with nKode for device recovery. If a user delegates authentication recovery to a few trusted people and they've lost their device, the user can go to any of their trusted delegates to enroll a new device through their delegate's nKode app. Users can configure account delegation such that any authentication can be completed with only one delegate or require more than one delegate to authenticate on the user's behalf. Once a device has been enrolled, the carrier can rely on nKode to authenticate a sim swap.

##### 4. Redline Stealer

Ideally, all nKode authentication goes through the mobile app. If authentication is done on a laptop, an attacker can steal a user's nKode after watching several nKode entries depending on the number of keys and attributes per key. This number can vary as the number of attributes and keys change.

##### 5. Exploiting SSO SAML

If an attacker finds a way to steal a user's nKode, they still need the user's device. The user's device contains their passkeys and biometrics. Without it, the adversary won't be able to authenticate.