fix(auth): reject custodial Lightning sign-in when stored signature is empty#3874
Draft
TaprootFreak wants to merge 1 commit into
Draft
fix(auth): reject custodial Lightning sign-in when stored signature is empty#3874TaprootFreak wants to merge 1 commit into
TaprootFreak wants to merge 1 commit into
Conversation
…s empty verifySignature returned `!dbSignature || signature === dbSignature` for the custodial-Lightning comparison branch. On sign-in, an account whose stored signature is empty/null (legacy accounts — see the 'temporary code to update empty signatures' self-heal in doSignIn) would authenticate with ANY signature matching the 140-146 alnum shape, then doSignIn persists the attacker's signature → permanent account takeover. Reachable via the public /auth/signIn (isCustodial defaults to false there, the regex is trivially satisfiable). A stored empty signature must never authenticate. Thread an isSignUp flag so sign-up still establishes the first signature (nothing stored yet) while sign-in requires an exact match against a non-empty stored signature — aligning Lightning with the DeFiChain branch right below, which already fails closed on an empty stored signature.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Finding (High, branch-weiter Security-Review)
verifySignaturenutzt für custodial Lightning den Vergleichs-Zweigreturn !dbSignature || signature === dbSignature. Bei Sign-in authentifiziert ein Account mit leerer/null gespeicherter Signatur damit über jede regex-konforme Signatur (/^[a-z0-9]{140,146}$/, trivial erzeugbar) — unddoSignInpersistiert danach die Angreifer-Signatur (else if (!user.signature)-Self-Heal) → permanenter Account-Takeover.Öffentlich erreichbar:
/auth/signInruft den Service ohneisCustodialauf (Defaultfalse), die Regex genügt also. Verifiziert:isCustodialist nicht angreiferkontrollierbar, aber auch nicht nötig.Gating: Existenz eines Lightning-Accounts mit leerer gespeicherter Signatur. Der Kommentar
// TODO: temporary code to update empty signaturesindoSignInund dienullableSignature-Spalte deuten stark darauf hin, dass solche (Legacy-)Accounts existieren.Fix
Eine leere gespeicherte Signatur darf niemandem Zugang geben. Ein
isSignUp-Flag wird durchgereicht:Das richtet Lightning am DeFiChain-Zweig direkt darunter aus, der mit
return dbSignature && signature === dbSignaturebereits fail-closed ist. Keine Krypto-Verifikation betroffen (EVM etc. laufen unverändert übercryptoService.verifySignature); der legitime Self-Heal für krypto-verifizierte Chains bleibt erhalten.Legacy-Lightning-Accounts mit leerer gespeicherter Signatur können sich nach diesem Fix nicht mehr über den Vergleichs-Pfad einloggen (es gibt kein Credential zum Verifizieren — genau das ist die Lücke). Das ist sicherheitstechnisch korrekt, kann aber legitime Altbestands-User aussperren. Empfehlung: vor dem Merge einen Count solcher Accounts ziehen (Lightning-Adresse +
signature IS NULL/''), um den Support-Impact abzuschätzen und ggf. einen Recovery-Pfad (Mail-Login) vorzubereiten. Self-Heal-TODO indoSignInbei der Gelegenheit mitbewerten.Tests
Neuer Spec
auth-lightning-signature.spec.ts: leere/null gespeicherte Signatur → abgewiesen; falscher Match → abgewiesen; korrekter Match → akzeptiert; Sign-up → etabliert.format:check,type-check,lintsauber; auth-Suite 20/20 grün.Damit ist der letzte High/Medium-Finding mit Account-Takeover-Potenzial adressiert. Verbleibend: SDK
x-kyc-codeohne Origin-Check (packages); Account-Merge Token-Bindung (Auth-Designentscheid).