2FA #5

New issue

Closed

opened 2025-02-27 11:24:38 +00:00 by StardustShard · 2 comments

StardustShard commented

2025-02-27 11:24:38 +00:00

Owner

TOTP and maybe WebAuthn but only as 2FA, not passwordless login

StardustShard commented

2025-03-16 17:00:01 +00:00

Author

Owner

totp_rs looks decent and mature enough, and i'd only need to add a table to hold the totps and recovery keys (one recovery key per TOTP, can be regenerated in the settings if the user loses theirs; lil form to check the recovery key? p2 or lil addition if i feel like it for now).

already have a QrCode generation lib and QrCode image integration on the site so i can build on that; the lib does seem to depend on and reexport a qrcode lib, may want to see if it's possible to not include that if i go my route.

[totp_rs](https://docs.rs/totp-rs/latest/totp_rs/) looks decent and mature enough, and i'd only need to add a table to hold the totps and recovery keys (one recovery key per TOTP, can be regenerated in the settings if the user loses theirs; lil form to check the recovery key? p2 or lil addition if i feel like it for now). already have a QrCode generation lib and QrCode image integration on the site so i can build on that; the lib does seem to depend on and reexport a qrcode lib, may want to see if it's possible to not include that if i go my route.

StardustShard referenced this issue

2025-03-16 17:01:49 +00:00

admin: user account admin ops interface #13

StardustShard added the

security

label 2025-03-16 17:02:56 +00:00

StardustShard commented

2025-03-16 17:16:56 +00:00

Author

Owner

table could look like so

user_id
otp_method
secret_seed
recovery_key
created_at
updated_at

primary key of (user_id, otp_method)

onboarding would be pretty standard:

in settings page, on the account part under the password section add a new OTP section to set and manage OTP
starting the OTP flow will bring to a separate page which will generate the secret seed and show the usual QrCode and raw base32 secret (or base64? if it works) in case the user doesn't have QrCode scan capabilities
to continue, form asking for the currently generated code (with a skew of 1, allowing the use of the previous secret or the next secret to handle clock skew)
if invalid, ask for another one; if valid, move to next step which is persisting the secret and generate a recovery key which is then presented to the user on the next page
from there they can simply go back to the settings page and totp is set

revocation would be a simple "are you sure?" page; there already are iirc so the revocation page could be made a bit more generic to avoid repeating and drifting on design

table could look like so * user_id * otp_method * secret_seed * recovery_key * created_at * updated_at primary key of (user_id, otp_method) onboarding would be pretty standard: * in settings page, on the account part under the password section add a new OTP section to set and manage OTP * starting the OTP flow will bring to a separate page which will generate the secret seed and show the usual QrCode and raw base32 secret (or base64? if it works) in case the user doesn't have QrCode scan capabilities * to continue, form asking for the currently generated code (with a skew of 1, allowing the use of the previous secret or the next secret to handle clock skew) * if invalid, ask for another one; if valid, move to next step which is persisting the secret and generate a recovery key which is then presented to the user on the next page * from there they can simply go back to the settings page and totp is set revocation would be a simple "are you sure?" page; there already are iirc so the revocation page could be made a bit more generic to avoid repeating and drifting on design

StardustShard added reference feat/totp

2025-03-16 17:23:44 +00:00

StardustShard added the

impl

doing

label 2025-03-16 17:23:48 +00:00

StardustShard referenced this issue from a commit

2025-03-19 12:19:32 +00:00

feat: TOTP 2FA, closes #5

StardustShard closed this issue

2025-03-19 12:19:39 +00:00