commit 878af909d2dd3283d40e745af7a87dd2cbfb2700 Author: Donovan Date: Sat Oct 26 15:01:08 2024 -0500 initial commit diff --git a/.idea/.gitignore b/.idea/.gitignore new file mode 100644 index 0000000..13566b8 --- /dev/null +++ b/.idea/.gitignore @@ -0,0 +1,8 @@ +# Default ignored files +/shelf/ +/workspace.xml +# Editor-based HTTP Client requests +/httpRequests/ +# Datasource local storage ignored files +/dataSources/ +/dataSources.local.xml diff --git a/.idea/modules.xml b/.idea/modules.xml new file mode 100644 index 0000000..51290bb --- /dev/null +++ b/.idea/modules.xml @@ -0,0 +1,8 @@ + + + + + + + + \ No newline at end of file diff --git a/.idea/nkode-landing-page.iml b/.idea/nkode-landing-page.iml new file mode 100644 index 0000000..5e764c4 --- /dev/null +++ b/.idea/nkode-landing-page.iml @@ -0,0 +1,9 @@ + + + + + + + + + \ No newline at end of file diff --git a/assets/advanced_settings.png b/assets/advanced_settings.png new file mode 100644 index 0000000..ad74029 Binary files /dev/null and b/assets/advanced_settings.png differ diff --git a/assets/baseball.png b/assets/baseball.png new file mode 100644 index 0000000..e2f1051 Binary files /dev/null and b/assets/baseball.png differ diff --git a/assets/confirm_nkode.png b/assets/confirm_nkode.png new file mode 100644 index 0000000..97e535e Binary files /dev/null and b/assets/confirm_nkode.png differ diff --git a/assets/ladybug.png b/assets/ladybug.png new file mode 100644 index 0000000..fd0b582 Binary files /dev/null and b/assets/ladybug.png differ diff --git a/assets/lightmodenkode.svg b/assets/lightmodenkode.svg new file mode 100644 index 0000000..6493b28 --- /dev/null +++ b/assets/lightmodenkode.svg @@ -0,0 +1,40 @@ + + + +TM diff --git a/assets/logged_in.png b/assets/logged_in.png new file mode 100644 index 0000000..574568b Binary files /dev/null and b/assets/logged_in.png differ diff --git a/assets/login1.png b/assets/login1.png new file mode 100644 index 0000000..2659d66 Binary files /dev/null and b/assets/login1.png differ diff --git a/assets/login2.png b/assets/login2.png new file mode 100644 index 0000000..176f9ad Binary files /dev/null and b/assets/login2.png differ diff --git a/assets/n.png b/assets/n.png new file mode 100644 index 0000000..b557e0c Binary files /dev/null and b/assets/n.png differ diff --git a/assets/pizza.png b/assets/pizza.png new file mode 100644 index 0000000..5af4099 Binary files /dev/null and b/assets/pizza.png differ diff --git a/assets/set_nkode.png b/assets/set_nkode.png new file mode 100644 index 0000000..e45197e Binary files /dev/null and b/assets/set_nkode.png differ diff --git a/assets/signup.png b/assets/signup.png new file mode 100644 index 0000000..f1d59b6 Binary files /dev/null and b/assets/signup.png differ diff --git a/assets/wine.png b/assets/wine.png new file mode 100644 index 0000000..cf80a47 Binary files /dev/null and b/assets/wine.png differ diff --git a/index.html b/index.html new file mode 100644 index 0000000..98e0b17 --- /dev/null +++ b/index.html @@ -0,0 +1,290 @@ + + + + + + + + + nKode + + + + + + + + +
+
+ + + +
+
+
+

+ 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. +
  2. You're redirected to a site with your nKode interface requesting authorization with your nKode.
    3. +
  3. You enter your nKode, but you're informed you entered the wrong nKode.
    4. +
  4. The attacker disperses your interface and requests you enter your nKode again.
    5. +
  5. You enter it again, and your nKode is stolen.
    6. +
+

+ 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. +
  2. The server-side attributes are rotated, and an intermediate transformation is applied to the user's server-side keys
    3. +
  3. Has a successful login, and the user's keys, salt, and hash are all replaced.
    4. +
+ +

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. +
  2. The solutions below will use the terms customers and mobile carriers, but these are interchangeable with employee and service desk.
    3. +
+
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. +

+
+
+
+ +
+ + + + + diff --git a/nginx.config b/nginx.config new file mode 100644 index 0000000..a8d0880 --- /dev/null +++ b/nginx.config @@ -0,0 +1,69 @@ +# Redirect all traffic from www.nkode.tech to nkode.tech +server { + listen 80; + server_name www.nkode.tech; + + return 301 https://nkode.tech$request_uri; +} + +server { + listen 443 ssl http2; + server_name www.nkode.tech; + + ssl_certificate /etc/letsencrypt/live/nkode.tech/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/nkode.tech/privkey.pem; + ssl_trusted_certificate /etc/letsencrypt/live/nkode.tech/chain.pem; + + return 301 https://nkode.tech$request_uri; +} + +# Main server block for nkode.tech +server { + listen 443 ssl http2; + server_name nkode.tech; + + ssl_certificate /etc/letsencrypt/live/nkode.tech/fullchain.pem; + ssl_certificate_key /etc/letsencrypt/live/nkode.tech/privkey.pem; + ssl_trusted_certificate /etc/letsencrypt/live/nkode.tech/chain.pem; + + ssl_protocols TLSv1.2 TLSv1.3; + ssl_prefer_server_ciphers on; + ssl_dhparam /etc/ssl/certs/dhparam.pem; + ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'; + ssl_session_cache shared:SSL:10m; + ssl_session_timeout 10m; + ssl_stapling on; + ssl_stapling_verify on; + resolver 8.8.8.8 8.8.4.4 valid=300s; + resolver_timeout 5s; + + add_header X-Content-Type-Options nosniff; + add_header X-Frame-Options DENY; + add_header Referrer-Policy "no-referrer-when-downgrade"; + add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; + + root /var/www/webapp; + index index.html index.htm; + + location / { + try_files $uri $uri/ /index.html; + } + + error_page 404 /404.html; + location = /404.html { + root /var/www/webapp; + } + + error_page 500 502 503 504 /50x.html; + location = /50x.html { + root /var/www/webapp; + } +} + +# Redirect HTTP to HTTPS for nkode.tech +server { + listen 80; + server_name nkode.tech; + + return 301 https://$host$request_uri; +}