GetPassword minted a brand-new random SRP server secret and B on every call while only ever assigning SRPID once (when zero). Two account.getPassword calls in a row -- e.g. a settings screen refreshing state, then the transfer- ownership dialog's own cloudPassword().reload() moments later -- silently invalidated each other's B with no signal the client could detect (SRPID unchanged), so a password check built from the first response's B failed with PASSWORD_HASH_INVALID even though the typed password was correct. The challenge now stays stable across reads and only rotates when it's missing entirely; UpdatePasswordSettings/RecoverPassword already mint their own fresh challenge whenever the password actually changes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| business.go | ||
| business_test.go | ||
| doc.go | ||
| email_signup_phone_change_test.go | ||
| lifecycle.go | ||
| lifecycle_test.go | ||
| login_email_test.go | ||
| phone_change.go | ||
| phone_change_test.go | ||
| service.go | ||
| service_test.go | ||
| srp.go | ||