How to 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 re-entering it.

4. Login with nKode

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

How nKode Works

Keypad Settings

Your nKode keypad is configurable. Under advanced settings, you can change the number of keys and the number of icons per key.

Account Creation

The server is able to deduce your nKode from two entries. In the set and confirm keypads below, no icon in the set keypad share a key with any other icon in the confirm keypad. This is called an icon dispersion.

Icon Dispersion

The login keypad looks different from the set and confirm keypads. It has three more icons per key. A dispersion is possible if the number of icons per key is less than or equal to the total number of keys. Since the login keypad has more icons per key than keys, we call this a dispersion-resistant keypad. If a malicious actor steals your keypad, they can use your keypad to phish for your nKode. If the login keypad 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 keypad requesting authorization with your nKode.
3. You enter your nKode, but you're informed you entered the wrong nKode.
4. The attacker disperses your keypad 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 icons per key and the number of keys, the greater the dispersion resistance. This 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 icons per key, your keypad becomes more dispersable. If you have too many icons and keys, the keypad is too busy, making it challenging to find your icons.

Server-Side Attributes

A traditional password is composed of ASCII and sometimes Unicode characters. These are salted, hashed, and stored in a database. nKode is similar. An unsigned 64-bit integer represents every icon, though it can be a byte array of any size. These server-side attributes can be rotated daily, weekly, or any other frequency 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. After a successful login, and the user's keys, salt, and hash are all replaced.

Login

Every time you log in, your icons are randomly shuffled. Icons don't move to arbitrary locations within the key; icons 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 icons haven't moved, some moved to other keys as a group, and some moved to different keys alone.

FAQ

When can I use nKode?

We're working to make nKode available through Auth0. However, we are looking for a strategic partner in identity management. If you are interested in working with nKode, please reach out.

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. 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 keypad can be made from any type of image. To make this more concrete, take a look at Flaticon. If every employee at the service desk has a randomly generated keypad from abstract images like those found on Flaticon, an employee would have difficulty explaining their nKode. Moreover, this keypad can be further protected with a 2FA keycard so only the employee can render their keypad. 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 icons 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 icons per key. This number can vary as the number of icons 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.

Contact Us

We'd love to hear from you! Whether you have questions, or feedback, feel free to reach out to us at: