TOTP / MFA login discussions #554

rishabhpoddar · 2023-01-12T07:12:03Z

Google doc link: https://docs.google.com/document/d/1qyd4XmepLJXNC4uURcak-7JbWP0UuzOPSsjBInVAuNk/edit

TODO:

(emails.length > 0 && query param has setup (is missing || is false)) -> call createCode
(emails.length === 0 || query param has setup=true) -> show enter email screen

The text was updated successfully, but these errors were encountered:

rishabhpoddar · 2023-01-12T07:12:13Z

SQL Table schema

CREATE TABLE IF NOT EXISTS totp_user_devices (
   user_id VARCHAR(128) NOT NULL,
   device_name VARCHAR(256) NOT NULL,
   secret_key VARCHAR(256) NOT NULL,
   period INTEGER NOT NULL,
   skew INTEGER NOT NULL,
   verified BOOLEAN NOT NULL DEFAULT FALSE,
   PRIMARY KEY (user_id, device_name)
);
 
 
-- This table needs to be cleared regularly (once an hour).
-- This table also contains codes that the user entered which did not succeed so that we can implement brute force protection
CREATE TABLE IF NOT EXISTS totp_used_codes (
   user_id VARCHAR(128) NOT NULL,
   code VARCHAR(6) NOT NULL,
   is_valid_code BOOLEAN NOT NULL,
   expiry_time BIGINT NOT NULL, -- 90 seconds in the future
   PRIMARY KEY (user_id, code)
   FOREIGN KEY (user_id) REFERENCES totp_user_devices(user_id) ON DELETE CASCADE
);

if there are no verified devices and the allowUnverifiedDevice boolean is false in the verify API, we do not insert the tried code into the totp_used_codes table cause we didn't reach a point of even verifying the code.

rishabhpoddar · 2023-01-12T07:12:19Z

Core APIs spec

POST /totp/device

Input body

{
 "deviceName": "My Authy Account",
 "userId": "UUIID of first factor (but it can be any string)",
 "skew": "integer",
 "period": "integer"
}

Output body

[{
 "status": "OK",
 "secret": "<32char-base32-random-secret>",
},
{
 "status": "DEVICE_ALREADY_EXISTS_ERROR"
}]

POST /totp/verify

Input body

{
 "userId": "UUIID of first factor (but it can be any string)",
 "totp": "123456",
 "allowUnverifiedDevice": "bool"
}

Output body

{
 "status": "OK | INVALID_TOTP_ERROR | TOTP_NOT_ENABLED_ERROR | LIMIT_REACHED_ERROR"
}

If there are no verified devices, we still return INVALID_TOTP_ERROR

POST /totp/device/verify

Input body

{
 "userId": "UUIID of first factor (but it can be any string)",
 "deviceName": "My Authy Account",
 "totp": "123456"
}

Output body

[{
 "status": "OK",
 "deviceWasAlreadyVerified": "bool",
},
{
 "status": "INVALID_TOTP_ERROR | TOTP_NOT_ENABLED_ERROR | UNKNOWN_DEVICE_ERROR"
}]

POST /totp/device/remove

Input body

{
 "userId": "UUIID of first factor (but it can be any string)",
 "deviceName": "str"
}

Output body

{
 "status": "OK",
 "didDeviceExist": "bool",
} | {
 "status": "TOTP_NOT_ENABLED_ERROR"
}

PUT /totp/device

Input body

{
 "userId": "UUIID of first factor (but it can be any string)",
 "existingDeviceName": "str",
 "newDeviceName": "str",
}

Output body

{
 "status": "OK | TOTP_NOT_ENABLED_ERROR | DEVICE_ALREADY_EXISTS_ERROR | UNKNOWN_DEVICE_ERROR"
}

GET /totp/device/list

Input body

{
 "userId": "UUIID of first factor (but it can be any string)"
}

Output body

[{
 "status": "OK",
 "devices": [ 
   {"name": "<device-1-name>", "verified": "bool"},
   {"name": "<device-2-name>", "verified": "bool"},
  ]
}, {
 "status": "TOTP_NOT_ENABLED_ERROR"
}]

rishabhpoddar · 2023-01-12T07:13:34Z

Core API logic flow

POST /totp/device

Validate input
- verify that deviceName and userId are strings and that they are not empty
- verify that period and skew are integers and 30 <= period < 90 and 0 <= skew <= 2
Generate secretKey for user. It should be a random 32char base32 string.
Query to insert userId and deviceId into totp_user_devices table.
If query fails because of unique constraints on (user_id, device_name), respond with status: DEVICE_ALREADY_EXISTS_ERROR
If succeeds, return status: OK

INSERT INTO totp_user_devices (user_id, device_name, secret_key period, skew, verified) 
VALUES (${userId}, ${device_name}, ${secretKey}, ${period}, ${skew}, False);

Notes:

Don't change period unless really required. It will make the auth incompatible with most TOTP auth apps (Authy, Google Auth, etc)

POST /totp/verify

Validate input
- verify that userId is string, totp is integer, and allowUnverifiedDevice is bool.
Query the database to get all the devices and their secrets for the user.
If no device is found, return status: TOTP_NOT_ENABLED_ERROR.
If allowUnverifiedDevice is False, remove devices where verified is False. If no device remains after this step, return status: INVALID_TOTP_ERROR
Check totp_used_codes and count attempts (agg. sum across all devices for given user id) within last period + (period * skew * 2) seconds. If there are more than 5 (subject to change) entries with is_valid_code False, return status: LIMIT_REACHED_ERROR
Use some library to implement TOTP verification algorithm.
Run the TOTP verification algorithm for all the devices. Compare against multiple TOTPs based on skew/period.
Return status: OK if any of the devices succeed. Otherwise, status: INVALID_TOTP_ERROR

SELECT device_name, secret_key, period, skew, verified FROM totp_user_devices
WHERE user_id = ${userId};

Notes:

The default values are a period of 30 and a skew of 1. It is highly recommended you do not change these unless you wish to set skew to 0 (more security but might cause poor user experience)

POST /totp/device/verify

Validate input
- verify that userId & deviceName are strings and totp is integer.
Query the database to all the devices for the user.
If no device is found, return status: TOTP_NOT_ENABLED_ERROR.
If devices are found but none matches the provided device name return status: UNKNOWN_DEVICE_ERROR
If device is found and is already verified return {status: OK, deviceWasAlreadyVerified: True}
If device is found and is not verified yet, use totp algorithm to check the code and return {status: OK, deviceWasAlreadyVerified: False} if it succeeds.
If verification fails, return status: INVALID_TOTP_ERROR

-- Fetch secret of given (user, device)
SELECT device_name, secret_key, period, skew, verified FROM totp_user_devices
WHERE user_id = ${userId} AND device_name = ${deviceName};

-- Mark the device as verified
UPDATE totp_user_devices
SET verified = True
WHERE user_id = ${userId} AND device_name = ${deviceName}

POST /totp/device/remove

Validate input
- Verify that userId & deviceName (Note that SDKs will make seperate query to check that provided TOTP is valid)
Query the database to see all the devices that exists for the user.
If no device is found, return status: TOTP_NOT_ENABLED_ERROR.
If devices are found but doesn't match the provided deviceName, return {status: OK, didDeviceExist: False}
If device is matched, delete it and return {status: OK, didDeviceExist: True}

few points:

This API doesn't care whether the device is verified or not.
Deleting all the devices would mean that TOTP gets disabled.

-- Fetch device_names for given user.
SELECT device_name FROM totp_user_devices
WHERE user_id = ${userId};

-- Delete the device
DELETE totp_user_devices
WHERE user_id = ${userId} AND device_name = ${deviceName};

PUT /totp/device

Validate input
- Verify that userId, existingDeviceName & newDeviceName are string
Query the database to see all the devices that exists for the user.
If no device is found, return status: TOTP_NOT_ENABLED_ERROR.
If devices are found but doesn't match the provided oldDeviceName, return status: UNKNOWN_DEVICE_ERROR
If device is matched, update its name. If succeeds, return status: OK
If update fails because of UNIQUE constraint on (user_id, device_name) pair. return status: DEVICE_ALREADY_EXISTS_ERROR

-- Fetch device_names for given user.
SELECT device_name FROM totp_user_devices
WHERE user_id = ${userId};

-- Delete the device
UPDATE totp_user_devices
SET device_name = ${newDeviceName}
WHERE user_id = ${userId} AND device_name = ${oldDeviceName};

Notes:

Not allowing users to modify skew/period for the device. They need to delete and create a new device.

GET /totp/device/list

Validate input
- Verify that userId is a string
Query the database to list all the devices that exists for the user.
If no device is found, return status: TOTP_NOT_ENABLED_ERROR.
Otherwise return {status: OK, devices: [{name: device1Name, verified: bool}, ...]}

-- Fetch all devices for given user.
SELECT device_name, verified FROM totp_user_devices
WHERE user_id = ${userId};

rishabhpoddar · 2023-01-12T07:15:15Z

Backend SDK API interface (node js)

export type TOTPAPIInterface = {
    // Skew and Period values are taken from the config not the user.
    createNewDevicePOST?: ((input: { session: SessionContainer; deviceName: string}) => Promise<
        { status: "OK", secret: string } | { status: "DEVICE_ALREADY_EXISTS_ERROR" }
    >);
   // allowUnverifiedDevice is taken from config not the user
    verifyTotpPOST?: ((input: { session: SessionContainer; totp: string }) => Promise<
        { status: "OK" | "INVALID_TOTP_ERROR" | "TOTP_NOT_ENABLED_ERROR" | "LIMIT_REACHED_ERROR" }
    >);
    verifyDevicePOST?: ((input: { session: SessionContainer; deviceName: string; totp: string }) => Promise<
        { status: "OK"; "deviceWasAlreadyVerified": boolean } | { status: "UNKNOWN_DEVICE_ERROR" | "INVALID_TOTP_ERROR" | "TOTP_NOT_ENABLED_ERROR" }
    >);
    removeTOTPDevicePOST?: ((input: { session: SessionContainer; deviceName: string }) => Promise<
        { status: "OK", "didDeviceExist": boolean } | { status: "TOTP_NOT_ENABLED_ERROR" }
    >);
  updateTOTPDevicePUT?: ((input: { session: SessionContainer; existingDeviceName: string; newDeviceName: string; userContext: any }) => Promise<
        { status: "OK" } | { status: "TOTP_NOT_ENABLED_ERROR" | "UNKNOWN_DEVICE_ERROR" }
    >);
    listTOTPDevicesGET?: ((input: { session: SessionContainer; }) => Promise<
        { status: "OK", devices: { name: string, verified: boolean }[] } | { status: "TOTP_NOT_ENABLED_ERROR" }
    >);
}

rishabhpoddar · 2023-01-12T07:15:23Z

Backend SDK recipe interface (node js)

export type TOTPRecipeInterface = {
    createNewDevice(input: { userId: string; deviceName: string; userContext: any }): Promise<
        { status: "OK", secret: string } | { status: "DEVICE_ALREADY_EXISTS_ERROR" }
    >;
    verifyTotp(input: { userId: string; totp: string; userContext: any }): Promise<
        { status: "OK" } | { status: "INVALID_TOTP_ERROR" | "TOTP_NOT_ENABLED_ERROR" }
    >;
    verifyDevice(input: { userId: string; deviceName: string; totp: string; userContext: any }): Promise<
        { status: "OK"; "deviceWasAlreadyVerified": boolean } | { status: "UNKNOWN_DEVICE_ERROR" | "INVALID_TOTP_ERROR" | "TOTP_NOT_ENABLED_ERROR" }
    >;
    removeDevice(input: { userId: string; deviceName: string; userContext: any }): Promise<
        { status: "OK", "didDeviceExist": boolean } | { status: "TOTP_NOT_ENABLED_ERROR" }
    >;
    updateDevice(input: { userId: string; existingDeviceName: string; newDeviceName: string; userContext: any }): Promise<
        { status: "OK" } | { status: "TOTP_NOT_ENABLED_ERROR" | "DEVICE_ALREADY_EXISTS_ERROR" | "UNKNOWN_DEVICE_ERROR" }
    >;
    listDevices(input: { userId: string; userContext: any }): Promise<
        { status: "OK", devices: { name: string, verified: boolean }[] } | { status: "TOTP_NOT_ENABLED_ERROR" }
    >;   
}

rishabhpoddar · 2023-01-16T11:03:42Z

rishabhpoddar · 2023-01-16T11:32:14Z

TODO for 2fa in general

Account for other 2fa types:
- Email OTP / magic link (passwordless recipe)
- SMS OTP / magic link (passwordless recipe)
- TOTP (totp recipe)
- other custom method that we don't support
Allowing developers to specify the 2fa that the app needs
Allowing developers to specify 2fa that each user has enabled
How this ties into 2fa session claim?

How is a factor defined?

It has a unique string representing a type of factor. We have a few inbuilt factors:
- "totp"
- "thirdparty"
- "emailpassword"
- "passwordless"
- We also allow users to define their own method..? TODO
requireFreshSince integer (decided to make it so that user can customise their way through this)
- This represents the amount of time after which the factor needs to be re asked. For example, if the user has finished totp in second factor now, and then totp is specified in the 4th factor as well, it won't be asked later as long as it's already done within 3600 seconds.
name (string)
- Used by the frontend to display the name of this factor when showing options.
- This is optional in the input that the user gives in the factors function, but normalised version is not optional.

recipeList: [
   MultiFactorAuth.init({
      factors: [
            {id: "thirdparty", order: 1}, {id: "emailpassword", order: 1}, 
            {id: "totp", order: 2}, {id: "passwordless", order: 2},
            {id: "totp", order: 3},
      ]
   })
]

If there are multiple factors on the same level, it means that any one of them can work
In the above example, if the user has finished totp in the second factor, then the 3rd factor will not ask totp to the user.
The UI for the first factor should pick the thirdpartyemailpassword recipe.
During sign up, the second factor will show options to the user (setup totp or email otp), and whichever they pick, will be enabled for them. Then later on in sign in, we will directly show them the enabled one. If the user has later on somehow enabled both the factors (for the second factor), then the sign in flow will ask the user for an option to pick which factor.
Constraints on the array:
- totp cannot be first factor

Defining a custom factor

recipeList: [
   Passwordless.init({
      flowType: "email_or_phone"
   }),
   MultiFactorAuth.init({
      factors: [
            {id: "passwordless", order: 1},
            {id: "biometric", name: "Biometric", order: 2},
      ]
   })
]

The only thing multi factor recipe will care about is that the id biometric is there in the session claim for 2fa.

Reusing a current recipe multiple times (decided not to do this now)

recipeList: [
   Passwordless.init({
      flowType: "email_or_phone"
   }),
   Passwordless.init({
      flowType: "phone",
      rid: "custom"
   }),
   MultiFactorAuth.init({
      factors: [
            {id: "passwordless", order: 1},
            {id: "passwordless", name: "SMS OTP", rid: "custom", order: 2},
       ]
   })
]

The idea here is that we allow each factor to point to a rid which will enable users to specify the same recipe multiple times in the recipe list (as shown above). Here we have two Passwordless recipes, one with email_or_phone (which will be on the first factor) and one with only phone which points to the second factor (custom rid)

Recipe function to get factors

There needs to be a recipe function which determines what the next factor to apply is. This is overridable by the user:

getFactors: (session?: SessionContainer, userContext) => {
   if (session !== undefined) {
      // first query core to get factors based on user id (SELECT * FROM mfa_factor WHERE user_id = <user-id>;)
      // if found, update the result to have the first factor from calling config.factors and return that.
   }
   return config.factors;
}

2fa session claim structure

Need to capture:

How many factors are completed
How many factors are not completed
For each factor:
- id of the factor
- if factor is completed or not
- time it was completed was last updated.
- order of this factor

{
   "st-mfa": {
      "v": {
         id: "...",
         c: "..." // "c" for completed with a boolean value
         t: "...", // time this factor was completed
         o: number // factor order
      }[]
   }
}

Alt: Make v {'factor_id': {c: bool, t: int, o: int}} (i.e. dict instead of list). This makes it easier for devs to access a factor's attrs.

fetch_value implementation for st-mfa claim:

Will call the getFactors function.
Transform the data structure to the claim type.

2fa session claim validators

hasCompletedAllFactors(toCheckFactorIds?: string[])
- this is to be added to the global validators as well.
- TODO: What happens if I pass in an id which is not configured for the user at all.
hasCompletedFactorWithinTime(factorId: string, time: number)

Step up auth

The dev can use hasCompletedFactorWithinTime validator to achieve this. If they want the user to always reauth, then they should put a low number.

How this ties in with email verification check

By default, we can make it so that the emailverification.isVerified validator is checked after the hasCompletedAllFactors validator - by having the isVerified validator AFTER the hasCompletedAllFactors in the global validator array. This would mean that email verification happens after all factors are completed.

If the user wants to change this order, then can shuffle the global claim validator array themselves. But is this a good way of doing it? TODO

Alt: We can use the factors config of MFA recipe to allow the user to decide the order of email verification.

rishabhpoddar · 2023-01-19T05:42:06Z

Different user flows (TODO):

Register the user:

Let's take the example of TPEP recipe, its signup_post func calls emailpassword.signup_post func.
Now emailpassword.recipe_implementation.sign_up calls create_new_session so the new session will contain the MFAClaim (value fetched based on getFactors func). Here's how the claim structure would look like:

{
    "st-mfa": {
        "v": [{
            id: "emailpassword",
            c: True,
            t: 123,
            o: 1
        },
        {
            id: "thirdparty",
            c: False,
            t: 0,
            o: 1
        },
        {
            id: "totp",
            c: False,
            t: 0,
            o: 2,
        },
        ]
    }
}

Now, 2nd factor(s) are present in the MFA claim but the c value is False (i.e. not completed). Now we query the core to see if user(id) has any TOTP registration attached or not. If not, we redirect to the TOTP device registration page. If TOTP device verification is required, users need to do that first and then only the TOTP entry of the MFA claim will be marked as completed.
Similarly, if there are more factors, we can redirect to respective pages one by one for each layer. If multiple factors are valid for a level/order allow any of them.

User adds a MFA (say TOTP) after registration:

First factor:

Already completed. They are signed in.

Second factor:

User clicks something that's equivalent of a "Enable TOTP" button.
~~Frontend calls POST /auth/mfa/factor API of Backend SDK with totp: True. It checks if TOTP is allowed by the dev based on MFA getFactors().~~
If allowed, SDK calls core API POST /mfa/factor with user_id and factor order info (here order: 2). Core adds an entry for the user in mfa_factor table.
Backend refetches the mfaClaim using fetchAndSetClaim.
Frontend gets back OK response and then it now asks the backend to query core for whether the user(id) has a TOTP device.
Assuming no existing TOTP devices for the user, core replies to the backend that no device is registered for the user(id). So now the backend will create a new request to the core to register a TOTP device.
This attaches user(id) with a new TOTP device entry and returns a URI that gets converted to QR code by the frontend.
Assume TOTP device verification is required and user enters that via the input box. Backend will verify the TOTP using POST /totp/device/verify API call to the core. If it succeeds, backend updates the TOTP entry of the MFA claim value to be c: True and assigns t the time of completion.

Logging in a user:

First factor:

User enters valid email and password. Server replies back with session tokens that contain MFA claim.
access_token_payload contains all the factors based on getFactors(). Only emailpassword entry has c: True. However, entry with id: totp will have c: False.

2nd factor:

2nd factor has only one option in this example i.e. TOTP. So we query the core to find if a device is attached to the user(id).
If so, redirect the user to TOTP verification page. User enters TOTP. If it's correct. Mark the TOTP factor as c: True and set its t value.
If not, prompt the user to register a TOTP device first (provided TOTP factor isn't optional)

Validating if a certain factor has been completed:

Use mfaClaim.validators.hasCompletedAllFactors(["totp"])

Accessing any protected API:

mfaClaim.validators.hasCompletedAllFactors if called without any arg ensures that all atleast one factor from each order/level has been completed. This is added to global claim validators list. So, using verifySession will enforce this on any custom API.

Disabling a factor (say TOTP):

User clicks something that's equivalent of a "Disable TOTP factor" button.
Frontend calls backend API PUT /auth/mfa/factor with totp: False
First the backend calls core API PUT /mfa/factor with totp: False.
- If the provided factor (here TOTP) is the only factor in its order/level, decrement order of all factors in the higher orders and remove the factor itself from mfa_factor table
- Otherwise if there are multiple in the same order/level, just remove the (TOTP) factor entry from mfa_factor table.
Refetch MFA claim and update the session using fetch_and_set_claim.
Note that TOTP devices corresponding to the user haven't been deleted here. TODO: Can this cause any issues?

Re-enabling a factor (say TOTP):

User clicks something that's equivalent of a "Enable TOTP" button.
Frontend calls backend API PUT /auth/mfa/factor with totp: True
Backend checks the factor config to extract the order/level of the factor (here TOTP is should have order 2)
Rest of the steps are same as User adds a MFA (say TOTP) after registration (starting from point 3)

KShivendu · 2023-01-25T10:40:00Z

SQL Table Schema:

CREATE TABLE IF NOT EXISTS mfa_factor (
    user_id VARCHAR(128) NOT NULL, -- Assume this is final user ID after account linking feature is completed.
    order INTEGER NOT NULL, -- Factor order. This is the position of the factor in the user's list of factors. There can be multiple factors at the same position.
    id VARCHAR(128) NOT NULL, -- Type of factor. Can be "totp", "email-otp", "sms-otp", etc. Alternatively can be called as factor_flow or factor_name
    PRIMARY KEY (user_id, order, id)
);

The reason for order and type in primary key is it if user wants to have multiple modes in same factor order. Example: TOTP as well as email-otp in 2nd factor.
This table should only store second factor onwards (cause we don't have the user ID before the first factor is completed). We can communicate this by throwing an error from the core if someone inserts into this table with order = 1.

KShivendu · 2023-01-25T10:40:17Z

Core API spec

Should we reuse usermetadata recipe/tables to store all the factor metadata?

POST /mfa/factor

{
 "user_id": "user_id",
 "factors": [
   [
    // [{"thirdpartyemailpassword": "tpep-user-id"}], // What will happen when account linking is enabled? // No benefit of providing first factor
    [{"totp": "enabled", "email-otp": "disabled"}],  // Just store that factor has been enabled/disabled/configured.
   ],
  ]
}

{
 "status": "OK"
}

GET /mfa/factor/list

Request body:

{
 "user_id": "<user-id-after-account-linking>"
}

Response body:

{
 "status": "OK",
 "factors": [
    [{"thirdpartyemailpassword": "enabled"}] 
    [{"totp": "enabled"}, {"email-otp": "enabled"}, ]
   ],
}

PUT /mfa/factor

Request body:

{
 "status": "OK",
 "factors": [
   {"totp": False}
  ]
}

Response body:

{
  "status": "OK | UNKNOWN_FACTOR_ERROR",
  "unknown_factor": "<factor>"
}

Updates enable column of a factor if it's already there. Otherwise, raises error.

rishabhpoddar · 2023-01-27T06:54:59Z

Changes to passwordless recipe

Expose an API which will help the frontend know if it's been configured or not for this user ID.

Reuse passwordless.recipe_impl.get_user_by_id(). Create an API for that.

Changes to emailpassword

If this is used in step up auth, and if there is no emailpassword user for the logged in user, we will ask the user to create a password.

Reuse signup/email/exists API. Create new API. But will we ask for email as well? (along with password). If no, will anything break in DB/core?

Changes to thirdparty

If using this in step up auth, and if there is no thirdparty user, then you ask them to choose an account (and then that is linked)

Changes to totp

If not configured, we will ask the user to setup.

TODO:

We need to make this configurable -> can be possibly done via overrides in some way??
Think about this whole flow.

KShivendu · 2023-02-08T08:37:12Z

TODO:

Think if we really need validate_factors since it's kinda redundant for now. See if there's a real usecase for this.
Inserting factors dynamically using based on previous factor.

During sign in: when emailpassword factor is completed, we want to show the email verification screen in case the second factor is going to be TOTP. If the second factor is going to be passwordless, then we want to mark the email verification claim as completed automatically.
During sign up: we want to do emailpassword -> email verification -> totp -> access

TOTP don't ask next 30 days on this device

Cases:

1:

During sign in: when emailpassword factor is completed, we want to show the email verification screen if the second factor is going to be TOTP. If the second factor is going to be passwordless, then we want to mark the email verification claim as completed automatically.
During sign up: we want to do emailpassword -> email verification -> totp -> access

mfa.init(
  factors=[
   Factor("emailpassword", 1),
   Factor("totp", 2), Factor("pless", 2),
  ]
)

def completed_factor(session, factor, context):
    if factor == Factor("totp", 2):
        redirect("/email-verification-screen")
    if factor == Factor("pless", 2):
        EVClaim.complete()

def get_factors(session, completed_factors: List[Factor], context) -> List[Factor]:
    # all_factors = self.get_all_factors()
    if Factor("totp", 2) in completed_factors:
        redirect("/email-verification-screen")
    if Factor("passwordless", 2) in completed_factors:
        EVClaim.complete()

    return oi_get_factors(session, completed_factors, context)

# Only the factors that remain in get_factors() will be allowed in the access token payload.

Alt:

mfa.init(factors=["emailpassword", "totp"])

def next_factors(session, completed_factors: List[Factor], context) -> List[Factor]:
    if Factor("emailpassword", 1) in completed_factors:
        return [Factor("totp", 2), Factor("pless", 2)] # When any of them is completed, we will remove the other one
    if Factor("totp", 2) in completed_factors:
        redirect("/email-verification-screen") # TODO: How will it redirect?
    if Factor("pless", 2) in completed_factors:
        EVClaim.complete()
        return []
    
    return oi_next_factors()

2:

User logs in -> email password -> totp -> checked on remember this device -> access
User logs in second time -> email password -> access (cause they clicked on rememeber this device)

mfa.init(factors=["emailpassword", "totp"])

def next_factors(session, completed_factors: List[Factor], context) -> List[Factor]:
    if completed_factors == [Factor("emailpassword", 1)] and context["flow"] == "login":
        device_exist = core.query()
        if device_exist:
           return []
    
    return oi_next_factors(session, completed_factors, context)

3:

Sign up: email password -> present a choice of totp or passwordless -> if totp is selected, then do that and email verification. If passwordless is selected, then do passwordless only.
Sign in: email password -> if totp is enabled, do totp, else do passwordless.

mfa.init(factors=["emailpassword", "passwordless"])

def next_factors(session, completed_factors: List[Factor], context) -> List[Factor]:
    if completed_factors == [Factor("emailpassword", 1)] and context["flow"] == "login":
          return [Factor("totp", 2), Factor("passwordless", 2)]
   if Factor("totp", 2) in completed_factors:
          redirect("/email-verification-redirect")
   return oi_next_factors(session, completed_factors, context)

4:

Sign up: email password -> passwordless -> step up auth (if totp is enabled, then use totp, else ask the user for their password)
Sign in: email password => if totp is enabled, use that, else give access

// TODO: INCOMPLETE 
mfa.init(factors=["emailpassword", "passwordless"])

def next_factors(session, completed_factors: List[Factor], context) -> List[Factor]:
    if Factor("passwordless", 2) in completed_factors and context["flow"] == "login":
          is_totp_enabled = core.query()
          if is_totp_enabled:
              return [Factor("totp", 3)]
          else:
              return [Factor("emailpassword", 3)]
   return oi_next_factors(session, completed_factors, context)

5:

Sign up: email password -> passwordless -> step up auth (if totp is enabled, then use totp, else ask the user for their password)
Sign in: email password => if totp is enabled, use that, else force user to enable totp and then give access

6:

Sign in: email password -> passwordless -> if passwordless was done using a new IP address then ask for TOTP else give access.

mfa.init(factors=["emailpassword", "passwordless"])

def next_factors(session, completed_factors: List[Factor], context) -> List[Factor]:
    if Factor("passwordless", 2) in completed_factors and context["flow"] == "login":
          is_different_ip = check_request_ip()
          if is_different_ip:
              return [Factor("totp", 3)]

   return oi_next_factors(session, completed_factors, context)

7:

sign in: Email password -> if logged in after 30 days -> do passwordless -> totp -> access. If sign in before 30 days -> totp -> passwordless

mfa.init(factors=["emailpassword"])

def next_factors(session, completed_factors: List[Factor], context) -> List[Factor]:
    if completed_factors == [Factor("emailpassword", 1)] and context["flow"] == "login":
          days_elasped_since_login = db.query()
          if days_elasped_since_login > 30:
              return [Factor("passwordless", 3), [Factor("totp", 3)]]
          else:
              return [Factor("passwordless", 3), [Factor("totp", 3)]]

   return oi_next_factors(session, completed_factors, context)

KShivendu · 2023-02-08T10:17:23Z

Including step up auth factors in config.factors and mark them as completed ?

KShivendu · 2023-03-06T07:00:16Z

factor[]:
[{id: string, order: number}]

This can come from:

config
user ID (DB)

db:

-- userId -> factor[]
CREATE TABLE mfa_factors(
   user_id VARCHAR(32),
   factor jsonb,
   PRIMARY KEY (user_id)
);

function nextFactor(session?, completedFactors?, factors, userContext) => string[]

session will be optional during first factor auth
completedFactors is from the session if the session is available
factors is from the static config, unless there is a mapping in the db from session.getUserId() to factor[]
origibal impl of this function will simply get the next factor from the factors array based on order and the last order in the completedFactors array

Structure of claim in access token:

    "st-mfa": {
        "v": {
            "id": string,
            "t": number,
            "completed": boolean,
            "order": number,
        }[]
    }

mfaclaim:

fetchValue
- call nextFactor
completeFactorWithId
- mark all the factors with id completed
completeFactorWithIdAndOrder
- mark the factor with ID and order as completed
isCompletedWithId
isCompletedWithIdAndOrder

validators:

hasCompletedFactors (factor[]?)
- if input is empty, it will check for all factors being completed
- in this case, the function will call next_factor and see if that returns empty, then completed, else not completed.
hasCompletedFactorsWithinTime(factor[]?, time)
- returns success if all factors in the input have been completed within time

————————
Problems:

nextFactor needs the factors for the user, but that requires a db call. So doing that on each API call is bad
Function body of validators is not clear.

KShivendu · 2023-03-23T07:53:20Z

Alternatives considered:

Alt 1

What if we dump all the factors from the DB/config in the first factor login itself. FE can just follow that order.

Edge cases:

Step-up auth: If step-up auth happens, hasCompletedFactorsWithinTime throws an error so FE redirects to the factor completion page.
Existing session: If I just updated factors in session 2, existing session 1 will not get affected. I can continue accessing routes that only have hasCompletedFactors with no args. However, if a factor is passed as arg, I must have completed it. Furthermore, if devs want they can just revoke previous sessions whenever factors are updated.
Dynamic factors: One can change the factor by overriding next_factors behavior. Say I want to ask for TOTP only if 30 days have passed since the last login.

Pros:

Very few DB calls.

Cons:

Soln to Problems:

Set up an expiry and do DB calls only once.
Store factors stored in DB in the session payload during auth. Later on just remove them?

rishabhpoddar · 2023-10-05T10:48:57Z

About first factor login:

Tenant creation:

During tenant creation, we will specify which will be the first factors:

{
    "tenantId": "customer1",
    "thirdPartyEnabled": true,
    "emailPasswordEnabled": true,
    "firstFactors": ['f1', 'f2', ...],
    "defaultRequiredFactorsForUser": ['f1', 'f2', ...],

So the core will check that for each fN in the firstFactors list, if it's a known fN (for example emailpassword, or thirdparty), then that must also be enabled for this tenant. Otherwise send a 400 error. The list of known factors is NOT limited the recipe id - for ex, there is otp-phone which is fulfilled by the passwordless recipe, and in fact, there is no passwordless as a factor at all (see comment below). For unknown fN (like biometric), we just let it be as part of the first_factors and don't do anything with it.
firstFactors is optional argument, and by default it will be null in the db, which is != empty array. An empty array should just be treated as no first factors which is useless, but it's fine.
We also add an totpEnabled boolean which is similar to enabled booleans. We check for this in the create device, verify device and verify code APIs for the TOTP recipe, on a tenant level (even though some of these apis are app specific).
defaultRequiredFactorsForUser is optional, and by default it will be an empty array (or null, which means the same thing). It represents the input to the getMFARequirementsForAuth function.

Tenant info fetching

When we get info for a tenant, we need to also communicate the firstfactors array. We have to distinguish if that tenant does not have the firstFactors configured vs it has it configured, but just a sub set of the enabled methods. This can be easily done by returning an optional firstFactors in the tenant info.

If frontend uses dynamic login method: true

The frontend will call getLoginMethods API. This API will get the info from the tenant.
- If the tenant has a configured firstFactors array (even if it's empty), it will return that
- If there is nothing configured on the core, it will check if the user has defined the firstFactors array in the typeInput of the backend SDK, and if that's there, we will return the intersection of that and the enabled login methods for the tenant.
- If the backend sdk's firstFactor is also not defined, then we return the auth recipes that are enabled for this tenant.

If frontend does not use dynamic login methods:

The user has to configure the firstFactors array on the frontend and backend.
If they do not configure it (on frontend or backend), you just treat it as if all auth recipes that are initialised are first factors).

How will the backend sign in / up APis know about the first factor?

The sign in / up APis from the core will return if that has the first factor config enabled for it or not, for that tenant. it is important to distinguish not configured vs it not being a first factor.
For example, the email password sign up API from the core can return:

{
  "status": "OK",
  "user": {...},
  "firstFactorConfig"?: boolean

If firstFactorConfig is missing, it means that there is no firstfactor configuration for that tenant, otherwise we use the boolean.
If it's not configured on the core, we use the firstFactor from the backend's typeInput, else, we just assume it as true.

rishabhpoddar · 2023-10-06T10:19:05Z

About passwordless factor ID

Instead of having factor id for passwordless where we have "otp-mobile" etc.. We do NOT have factor ID of passwordless. The config for passwordless.init on the frontend and backend need to be a super set of all the factor IDs that getMFARequirementsForAuth can return.

porcellus · 2023-10-06T18:22:31Z

TODO

Planned return values for the default implementations of getMFARequirementsForAuth, getMFARequirementsForFactorSetup

Initialized recipes	First factors	Linked accounts (login methods)	Has TOTP device	getMFARequirementsForAuth(oneOf)	getMFARequirementsForFactorSetup(oneOf)
TP, EP, TOTP	undefined	TP	No	[totp]	[]
TP, EP, TOTP	undefined	TP	Yes	[totp]	[totp]
TP, EP, TOTP	undefined	TP, EP	No	[totp]	[]
TP, EP, TOTP	undefined	TP, EP	Yes	[totp]	[totp]
TP, EP, TOTP	TP	TP, EP	No	[totp, emailpassword]	[emailpassword, totp]
TP, EP, TOTP	TP	TP, EP	Yes	[totp, emailpassword, totp]	[emailpassword, totp]

porcellus · 2023-10-06T18:25:57Z

Factor ids associated with each recipe:

EmailPassword: emailpassword
ThirdParty: thirdparty
Passwordless: otp-phone, otp-email, link-phone, link-email
TOTP: totp
Other non-auth recipes do not have any factorIds associated with them.
Combination recipes: the union of the "sub-recipes"

porcellus · 2023-11-21T09:26:26Z

Meeting notes:

we'll change the behaviour of sign in/up APIs to NOT overwrite the session if one already exists, but still return success (status: "OK" )
apps will be able to revert to the old behaviour through a flag added to the session recipe (overwriteSessionDuringSignIn)
we will only allow factor setup when signing up (i.e.: do not link pre-existing accounts through the MFA recipe)
Just to clarify, if someone calls the createNewSession manually whilst they already have a session, that should override the current one.

rishabhpoddar · 2023-11-23T13:08:27Z

EDIT: 23rd November, 2023

For the default implementation of isAllowedToSetupFactor:

if the next array is empty, then we should allow
if not and any of the items in the array are set up, then you disallow.

porcellus · 2023-11-27T09:38:26Z

Implementing recovery codes (will be added as part of an example app):

Add API endpoints/UI to create/manage recovery codes (e.g.: save these into user metadata)
Add an endpoint that'll verify&save a recovery code into the session payload
Override isAllowedToSetupFactor to check if the access token payload has a valid recovery code.
Override factor setup to also remove the recovery code from the DB/user metadata
Implement a UI flow to reset:
1. Allow inputting the recovery code
2. After the recovery code is verified redirect to the factor chooser (or directly to a factor setup page)
3. Each factor can be forced into "setup mode" by adding ?setup=true to the URL or by overriding
4. getFactorsSetUpByUser to return empty if the user has a recovery code in the session.
Override UI components to add links pointing to the entry point of the above reset flow

porcellus · 2023-12-07T23:51:36Z

All TODOS have been moved from here to the main list

sattvikc · 2023-12-08T09:01:31Z

BE TODOs:

Change type of userContext to Record<string, any>
MFA tests

sattvikc · 2023-12-15T13:51:03Z

Flow for factor login: https://supertokens.slack.com/archives/C051BN9QJUX/p1702645397935389

no session -> normal operation
with session:
- mfa disabled ->
  - if session overwrite is not allowed -> we don’t do auto account linking and no manual account linking (even if user has switched on automatic account linking)
    - the 2nd account already exists -> no op (do not change the db)
    - the 2nd account does not exist -> isSignUpAllowed -> create a recipe user
  - if session overwrite is allowed -> we ignore the input session and just do normal operation as if there was no input session.
- mfa enabled -> we don’t do auto account linking (even if user has switched on automatic account linking)
  - the 2nd account already exists:
    - if user is already linked to first account -> modify session’s completed and next array
    - if user is not already linked to first account -> Contact support case (cause we can’t do account linking here cause the other account may have some info already in it, and we do not call shouldDoAutomaticAccountLinking function)
  - the 2nd account does not exist -> creating and linking (if linking is allowed, if not, we aren’t creating either + isAllowedToSetupFactor + (2nd factor is verification || login method with same email and its verified))
    - If linking is not allowed, we return a support status code
    - The code path should never use the session overwrite boolean in this case!

Logic for the above discussion:

mfa disabled
- no session (normal operation)
  - sign in
    - recipe signIn
    - check isSignInAllowed
    - auto account linking
    - create session
    - return
  - sign up
    - check isSignUpAllowed
    - recipe signUp (with auto account linking)
    - create session
    - return
- with session
  - sign in
    - recipe signIn
    - if overwriteSessionDuringSignInUp === true
      - check isSignInAllowed
      - auto account linking
      - create session
    - return
  - sign up
    - check isSignUpAllowed
    - if overwriteSessionDuringSignInUp === true
      - recipe signUp (with auto account linking)
      - create session
    - else
      - recipe signUp (without auto account linking)
    - return
mfa enabled
- no session (normal operation + check for valid first factor + mark factor as complete)
  - sign in
    - recipe signIn
    - check isSignInAllowed
    - check if valid first factor
    - auto account linking
    - create session
    - mark factor as complete in session
    - return
  - sign up
    - check isSignUpAllowed
    - check if valid first factor
    - recipe signUp (with auto account linking)
    - create session
    - mark factor as complete in session
    - return
- with session
  - sign in
    - recipe signIn
    - check isSignInAllowed
    - check if factor user is linked to session user (support code if failed)
    - mark factor as complete in session
    - return
  - sign up
    - check for matching verified email in session user (support code if failed)
    - check if allowed to setup (returns claim error if failed)
    - check if factor user can be linked to session user (if failed, support code / unauthorized)
    - recipe signUp (with auto account linking)
    - link factor user to session user (if failed, recurse or unauthorized)
    - create session
    - mark factor as complete in session
    - return

porcellus · 2024-01-02T12:42:40Z

Notes from 24.01.02 discussion:
Let’s look at this use-case:

the user is required to do email verification before setting up otp-phone (let's say to lower sms sending costs)
They can do this by:
- Overriding isAllowedToSetupFactor… on the BE
- Adding the MFA validator after the EV validator on the FE (I need to double check, but this can happen based on recipe init order as well)

In this case:

If we simply filter the next array and only add whatever is available at that point in time:
- the next array will be empty after an EP sign up
- this would make requests using that session pass the default MFA claim validator which is definitely not the right thing to do
If we filter the next array and add a special (access-denied) factor:
- The requests now fail the default MFA claim validator, which is the right thing
- What updates the next array in the claim? EV endpoints should not care about the MFA claim so they can’t. We’d end up relying on people calling the MFA info endpoint once again.
- Also we should avoid adding special cases like this if possible

What I propose instead:

We add a flag (v: boolean) to the MFA claim. This will explicitly flag if the session passes the default requirements or not, making it very easy to explain.
we can add a filtered next options array to the MFA info API response
we could drop the next array as we only really use it as a flag and as a way to provide hints about where to redirect/what to show on the chooser screen, but that can be achieved in other ways
- Doing it without increasing the redirection and call-count will require a tiny bit of caching on the FE and/or making the assumption that if you navigated to the factor screen you are allowed to either complete or set it up and just rely on the initial API calls to tell us otherwise.

The way we can communicate implementation for custom UIs:

Check if the flag is true
If false, call MFA info to see what to do next:
1. If the available next factors array is empty show an access denied screen
2. if the available next factors array has a single item go there
3. if the available next factors array has multiple items show a chooser

If someone wants to get smart and use the next array in the claim (if we choose to leave it there) they can do so, but that would not be the standard recommendation. Our implementation could still use it.

Changes:

Remove the next array from the claim and add the flag
Update the related validator to use the flag instead of the next array
Add a filtered (in next array && (in isAllowedToSetup || in isAlreadySetup) next array into the response of MFA info endpoint
Cache the MFA info response in the FE (we want to avoid adding the email/phone info into the query params and people were confused about using the hash before)
- One possible solution to explore: cache the info in session storage + add cache key as a query param.
- check how many requests we make when navigating to/refreshing a protected page, with and without a factor to redirect to
Update the claim failure redirection impl to use the MFA info API instead of the next array.
Update the docs to reflect the above recommendations

sattvikc · 2024-01-03T07:04:15Z

Jan 3, 2024

Invalid first factor error is not a support code but instead a 401 error. Support codes are only meant to be used when the implementations are all correct but the user is unable to complete something because of an application state. Invalid first factor is either user trying to call unintended API or a dev mistake or a config error.

rishabhpoddar · 2024-03-18T19:10:06Z

This has been released in core version >= 9.0, node SDK version >= 17.0

rishabhpoddar added the enhancement New feature or request label Jan 12, 2023

This was referenced Feb 9, 2023

feat: Define TOTP recipe plugin interface supertokens/supertokens-plugin-interface#53

Merged

feat: Implement TOTP inmemory classes #564

Merged

This was referenced Mar 14, 2023

feat: Implement TOTP recipe features supertokens/supertokens-postgresql-plugin#61

Merged

feat: Add support for TOTP recipe supertokens/supertokens-mysql-plugin#44

Merged

test: Add tests for active users update across different API calls #586

Merged

KShivendu mentioned this issue Mar 23, 2023

feat: Check TOTP feature flag in TOTP recipe functions #592

Merged

9 tasks

rishabhpoddar changed the title ~~TOTP login discussions~~ TOTP / MFA login discussions Mar 27, 2023

KShivendu mentioned this issue May 16, 2023

feat: Introduce TOTP recipe supertokens/supertokens-python#326

Closed

11 tasks

KShivendu mentioned this issue Jun 1, 2023

feat: Introduce TOTP recipe supertokens/supertokens-node#576

Closed

10 tasks

KShivendu mentioned this issue Jun 23, 2023

feat: Introduce MFA recipe supertokens/supertokens-node#604

Closed

12 tasks

This was referenced Nov 10, 2023

fix: MFA type updates supertokens/supertokens-node#737

Merged

fix: totp APIs and flaky tests fix #879

Merged

porcellus mentioned this issue Dec 14, 2023

MFA step-up auth #900

Open

rishabhpoddar mentioned this issue Dec 17, 2023

MFA docs supertokens/docs#763

Merged

83 tasks

This was referenced Dec 25, 2023

Mfa changes #901

Merged

feat: Multifactor authentication supertokens/supertokens-node#741

Merged

sattvikc mentioned this issue Jan 22, 2024

fix: createNewRecipeUser input in consume code API #910

Merged

13 tasks

sattvikc mentioned this issue Jan 29, 2024

fix: totp import api #915

Merged

13 tasks

This was referenced Mar 13, 2024

MFA design #648

Closed

[RELEASE]: MFA #953

Open

rishabhpoddar closed this as completed Mar 18, 2024

furkansenharputlu mentioned this issue Apr 26, 2024

fix: session required in signout supertokens/supertokens-golang#407

Merged

12 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TOTP / MFA login discussions #554

TOTP / MFA login discussions #554

rishabhpoddar commented Jan 12, 2023 •

edited

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 16, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 16, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 19, 2023 •

edited

Loading

KShivendu commented Jan 25, 2023 •

edited by rishabhpoddar

Loading

KShivendu commented Jan 25, 2023 •

edited

Loading

rishabhpoddar commented Jan 27, 2023 •

edited by KShivendu

Loading

KShivendu commented Feb 8, 2023 •

edited

Loading

KShivendu commented Feb 8, 2023 •

edited

Loading

KShivendu commented Mar 6, 2023 •

edited

Loading

KShivendu commented Mar 23, 2023 •

edited

Loading

rishabhpoddar commented Oct 5, 2023 •

edited

Loading

rishabhpoddar commented Oct 6, 2023 •

edited

Loading

porcellus commented Oct 6, 2023 •

edited by rishabhpoddar

Loading

porcellus commented Oct 6, 2023

porcellus commented Nov 21, 2023 •

edited by rishabhpoddar

Loading

rishabhpoddar commented Nov 23, 2023 •

edited

Loading

porcellus commented Nov 27, 2023

porcellus commented Dec 7, 2023 •

edited

Loading

sattvikc commented Dec 8, 2023

sattvikc commented Dec 15, 2023 •

edited

Loading

porcellus commented Jan 2, 2024

sattvikc commented Jan 3, 2024

rishabhpoddar commented Mar 18, 2024

TOTP / MFA login discussions #554

TOTP / MFA login discussions #554

Comments

rishabhpoddar commented Jan 12, 2023 • edited Loading

TODO:

rishabhpoddar commented Jan 12, 2023 • edited by KShivendu Loading

SQL Table schema

rishabhpoddar commented Jan 12, 2023 • edited by KShivendu Loading

Core APIs spec

POST /totp/device

Input body

Output body

POST /totp/verify

Input body

Output body

POST /totp/device/verify

Input body

Output body

POST /totp/device/remove

Input body

Output body

PUT /totp/device

Input body

Output body

GET /totp/device/list

Input body

Output body

rishabhpoddar commented Jan 12, 2023 • edited by KShivendu Loading

Core API logic flow

POST /totp/device

Notes:

POST /totp/verify

Notes:

POST /totp/device/verify

POST /totp/device/remove

few points:

PUT /totp/device

Notes:

GET /totp/device/list

rishabhpoddar commented Jan 12, 2023 • edited by KShivendu Loading

Backend SDK API interface (node js)

rishabhpoddar commented Jan 12, 2023 • edited by KShivendu Loading

Backend SDK recipe interface (node js)

rishabhpoddar commented Jan 16, 2023 • edited by KShivendu Loading

TODO

rishabhpoddar commented Jan 16, 2023 • edited by KShivendu Loading

TODO for 2fa in general

How is a factor defined?

Defining a custom factor

Reusing a current recipe multiple times (decided not to do this now)

Recipe function to get factors

2fa session claim structure

2fa session claim validators

Step up auth

How this ties in with email verification check

rishabhpoddar commented Jan 19, 2023 • edited Loading

Different user flows (TODO):

Register the user:

User adds a MFA (say TOTP) after registration:

Logging in a user:

Validating if a certain factor has been completed:

Accessing any protected API:

Disabling a factor (say TOTP):

Re-enabling a factor (say TOTP):

KShivendu commented Jan 25, 2023 • edited by rishabhpoddar Loading

SQL Table Schema:

KShivendu commented Jan 25, 2023 • edited Loading

Core API spec

POST /mfa/factor

GET /mfa/factor/list

Request body:

Response body:

PUT /mfa/factor

Request body:

Response body:

rishabhpoddar commented Jan 27, 2023 • edited by KShivendu Loading

Changes to passwordless recipe

Changes to emailpassword

Changes to thirdparty

Changes to totp

rishabhpoddar commented Jan 12, 2023 •

edited

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 12, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 16, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 16, 2023 •

edited by KShivendu

Loading

rishabhpoddar commented Jan 19, 2023 •

edited

Loading

KShivendu commented Jan 25, 2023 •

edited by rishabhpoddar

Loading

KShivendu commented Jan 25, 2023 •

edited

Loading

rishabhpoddar commented Jan 27, 2023 •

edited by KShivendu

Loading

KShivendu commented Feb 8, 2023 •

edited

Loading

KShivendu commented Feb 8, 2023 •

edited

Loading

KShivendu commented Mar 6, 2023 •

edited

Loading

KShivendu commented Mar 23, 2023 •

edited

Loading

rishabhpoddar commented Oct 5, 2023 •

edited

Loading

rishabhpoddar commented Oct 6, 2023 •

edited

Loading

porcellus commented Oct 6, 2023 •

edited by rishabhpoddar

Loading

porcellus commented Nov 21, 2023 •

edited by rishabhpoddar

Loading

rishabhpoddar commented Nov 23, 2023 •

edited

Loading

porcellus commented Dec 7, 2023 •

edited

Loading

sattvikc commented Dec 15, 2023 •

edited

Loading