diff --git a/authentication/email.mdx b/authentication/email.mdx index 2ae5c549..30790ef0 100644 --- a/authentication/email.mdx +++ b/authentication/email.mdx @@ -6,7 +6,7 @@ sidebarTitle: "Email" **One-Time Password** -- Uses a 6-digit one-time password sent via email +- Uses a 6-9 digit or bech32 alphanumeric one-time password sent via email - Simple, and familiar user experience **Credential Bundle** @@ -26,7 +26,6 @@ Email Authentication is built with expiring API keys as the foundation. The two The authentication process happens in two steps: - A 6-digit OTP code is sent to the user's verified email address Upon verification of the correct code, an API key credential is generated and encrypted for the client @@ -51,21 +50,20 @@ The flow begins with a new activity of type `ACTIVITY_TYPE_INIT_OTP_AUTH` with t - `userIdentifier`: optional parameter for rate limiting SMS OTP requests per user. We recommend generating this server-side based on the user's IP address or public key. See the [OTP Rate Limits](#otp-rate-limits) section below for more details. +- `alphanumeric`: optional parameter for making this code bech32 alphanumeric or not. default: true +- `otpLength`: optional parameter for selecting the length of the OTP. default: 9 -After receiving the 6-digit code, users complete authentication with `ACTIVITY_TYPE_OTP_AUTH`: +After receiving the OTP code, users complete authentication with `ACTIVITY_TYPE_OTP_AUTH`: - `otpId`: ID from the init activity -- `otpCode`: the 6-digit code received via email +- `otpCode`: the 6-9 digit or bech32 alphanumeric code received via email - `targetPublicKey`: public key for credential encryption - `apiKeyName`: optional name (defaults to `OTP Auth - `) - `expirationSeconds`: optional validity window (defaults to 15 minutes) - `invalidateExisting`: optional boolean to invalidate previous OTP Auth API keys - auth otp email + ![auth otp email](/images/authentication/img/auth_otp_email.png) ### OTP Rate Limits @@ -88,7 +86,7 @@ This alternative method uses `ACTIVITY_TYPE_EMAIL_AUTH` with these parameters: - `invalidateExisting`: optional boolean to invalidate previous Email Auth API keys - auth email + ![auth email](/images/authentication/img/auth_email.png) ### Recovery Flow @@ -104,7 +102,7 @@ The recovery process consists of two phases: 2. **Finalization**: User decrypts the recovery credential and uses it to sign an `ACTIVITY_TYPE_RECOVER_USER` activity, which can add new authenticators to regain account access - auth email + ![auth email](/images/authentication/img/auth_email.png) ## Authorization @@ -127,13 +125,10 @@ Specifically: ### Recovery - `ACTIVITY_TYPE_INIT_USER_EMAIL_RECOVERY`: - - Initiates the recovery process - Requires proper authorization via policies - Can target any user in the organization or sub-organizations - - `ACTIVITY_TYPE_RECOVER_USER`: - - Must be signed by the recovery credential received via email - Users can add credentials to their own user when authenticated - Recovery credentials expire after 15 minutes @@ -141,10 +136,7 @@ Specifically: - Users can add new authenticators to regain account access when authenticated with a recovery credential - email auth authorization + ![email auth authorization](/images/authentication/img/diagrams/email_auth_authorization.png) ## Implementation in Sub-organizations @@ -160,21 +152,13 @@ Both authentication methods and recovery work seamlessly with [sub-organizations For implementation details: - - - + + + + + + + ## Implementation in Organizations @@ -182,11 +166,9 @@ For implementation details: For organizations accessed via dashboard: 1. Ensure the required features are enabled: - - `FEATURE_NAME_OTP_EMAIL_AUTH` for OTP-based authentication - `FEATURE_NAME_EMAIL_AUTH` for credential bundle authentication - Recovery features if needed - 2. Users initiating the request must have appropriate permissions ## Opting Out @@ -205,10 +187,9 @@ When creating sub-organizations, use: - `disableEmailAuth` parameter for credential bundle authentication - `disableEmailRecovery` parameter for recovery -## Implementation Notes[​](#implementation-notes "Direct link to Implementation Notes") +## Implementation Notes[​](#implementation-notes) - Users are limited to: - - 10 long-lived API keys - 10 expiring API keys (oldest are discarded when limit is reached) @@ -246,4 +227,4 @@ turnkey request --host api.turnkey.com --path /public/v1/submit/set_organization "name": "FEATURE_NAME_EMAIL_AUTH" } }' --organization -``` +``` \ No newline at end of file diff --git a/authentication/sms.mdx b/authentication/sms.mdx index 963ec9bb..c098bc55 100644 --- a/authentication/sms.mdx +++ b/authentication/sms.mdx @@ -1,6 +1,6 @@ --- title: "SMS Authentication" -description: "SMS authentication enables users to authenticate their Turnkey account using their phone number via a 6-digit one-time password (OTP). When authenticated, users receive an expiring API key stored in memory within an iframe, which functions like a session key to access their wallet." +description: "SMS authentication enables users to authenticate their Turnkey account using their phone number via a 6-9 digit or bech32 alphanumeric one-time password (OTP). When authenticated, users receive an expiring API key stored in memory within an iframe, which functions like a session key to access their wallet." sidebarTitle: "SMS" --- @@ -8,13 +8,16 @@ sidebarTitle: "SMS" SMS authentication is available to all Enterprise customers. To enable this feature, please reach out to the Turnkey team. -SMS pricing is usage-based and varies depending on the country of the destination phone number. A downloadable price list for all supported countries is available here as a CSV. +SMS pricing is usage-based and varies depending on the country of the destination phone number. A downloadable price list for all supported countries is available +here as a CSV + +. ## How It Works SMS authentication uses two activities: -1. `INIT_OTP_AUTH` - sends a 6-digit OTP code to the specified phone number +1. `INIT_OTP_AUTH` - sends a 6-9 digit or bech32 alphanumeric OTP code to the specified phone number 2. `OTP_AUTH` - verifies the code and returns an encrypted API key credential ## Implementation @@ -28,13 +31,16 @@ To start SMS authentication, create an activity with `ACTIVITY_TYPE_INIT_OTP_AUT - `userIdentifier`: optional parameter for rate limiting SMS OTP requests per user. We recommend generating this server-side based on the user's IP address or public key. See the [OTP Rate Limits](#otp-rate-limits) section below for more details. +- `smsCustomizationParams`: optional parameters for customizing sms. +- `alphanumeric`: optional parameter for making this code bech32 alphanumeric or not. default: true +- `otpLength`: optional parameter for selecting the length of the OTP. default: 9 ### Verifying the OTP Once the user receives their code, use `ACTIVITY_TYPE_OTP_AUTH` with these parameters: - `otpId`: ID from the `INIT_OTP_AUTH` response -- `otpCode`: the 6-digit code received via SMS +- `otpCode`: the 6-9 digit or bech32 alphanumeric code received via SMS - `targetPublicKey`: public key for credential encryption - `apiKeyName`: optional name for the API Key (defaults to `OTP Auth - `) - `expirationSeconds`: optional duration in seconds (defaults to 15 minutes) @@ -44,7 +50,9 @@ Once the user receives their code, use `ACTIVITY_TYPE_OTP_AUTH` with these param SMS authentication requires proper permissions through policies or parent organization status. -Non-paying accounts are limited to **50 SMS messages** per month. + + Non-paying accounts are limited to **50 SMS messages** per month. + ## Enabling/Disabling SMS Auth @@ -80,4 +88,4 @@ In order to safeguard users, Turnkey enforces rate limits for OTP auth activitie - 3 requests per 3 minutes per unique `userIdentifier` - 3 retries max per code, after which point that code will be locked -- 3 active codes per user, each with a 5 minute TTL +- 3 active codes per user, each with a 5 minute TTL \ No newline at end of file diff --git a/networks/overview.mdx b/networks/overview.mdx index af95a26b..5791885c 100644 --- a/networks/overview.mdx +++ b/networks/overview.mdx @@ -29,12 +29,12 @@ Our SDK provides tools and scripts to help in constructing and signing basic tra At our highest level of support, Turnkey offers the ability to parse transactions and define custom policies based on transaction parameters. -| Tier | Depth of support | EVM | SVM | BTC | ATOM | TRON | SUI | APT | TON | XRP | SEI | -| ------ | :------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | -| Tier 1 | Curve-level | | | | | | | | | | | -| Tier 2 | Address derivation | | | | | | | | | | | -| Tier 3 | SDK construction and signing | | | | | | | | | | | -| Tier 4 | Transaction parsing and policies | | | | | | | | | | | +| Tier | Depth of support | EVM | SVM | BTC | ATOM | TRON | SUI | APT | MOVE | TON | XRP | SEI | FLARE | +| ------ | :------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | --------------------------------------------- | ----- | +| Tier 1 | Curve-level | | | | | | | | | | | | | +| Tier 2 | Address derivation | | | | | | | | | | | | | +| Tier 3 | SDK construction and signing | | | | | | | | | | | | | +| Tier 4 | Transaction parsing and policies | | | | | | | | | | | | | For more details about each ecosystem, refer to the pages below: diff --git a/security/reporting-a-vulnerability.mdx b/security/reporting-a-vulnerability.mdx index fbad2c14..3cab0ee7 100644 --- a/security/reporting-a-vulnerability.mdx +++ b/security/reporting-a-vulnerability.mdx @@ -4,7 +4,7 @@ description: "Turnkey highly values the security of our software, services, and mode: "wide" --- -If you believe you have found very serious vulnerability, we ask that you encrypt the message to the `security.turnkey.com` PGP key (FP: `AD6C 3E61 17A5 886E 550E F8BB 3ACD E5EA 8DC7 9275`). This can also be found on Turnkey's website at https://www.turnkey.com/.well-known/security.asc.txt +If you believe you have found a very serious vulnerability, we ask that you encrypt the message to the [security@turnkey.com](mailto:security@turnkey.com) PGP public key (fingerprint: `AD6C 3E61 17A5 886E 550E F8BB 3ACD E5EA 8DC7 9275`). You can find this key at https://www.turnkey.com/.well-known/security.asc Upon receiving a report, our team promptly assesses and prioritizes the vulnerability based on its severity and potential impact. We then take reasonable and appropriate steps to mitigate and remediate the identified risks in accordance with our internal policies and timelines. Where feasible, we will endeavor to keep the reporter informed throughout the process. Our approach is designed to ensure confidentiality and offer safe harbor to researchers, promising that those who report vulnerabilities ethically and in good faith will not face legal action.