halkyon-days/halkyon
Watch
1
0
Fork
You've already forked halkyon
 0
Code Issues Pull requests Projects Releases 37 Packages Wiki Activity Actions

fix(auth)!: proofs are bound to the instance the device addresses

Browse source 
Nothing tied a sign-in's proof to the instance it was made for: an
instance a person was lured into adding could pass A, M1 and the code on
to the real register and get a session there, and pass a phrase's proof
on with a password of its own in place of the person's (the second
reading's M6). SRP's identity is now a label, the challenge's ID and
the host the device addressed (passwordIdentity, in halkyon_base_client
and halkyon_base_server alike), and the phrase's proof signs that host,
what it is for (an authenticator's reset or a new password) and the new
password's digest (key proof v2). Every proving call carries the host;
in production it must be the server's apiServer.publicHost (otherwise
otherInstance, which the app shows as an instance it can't trust), in
development any; a member forwards its own. The tests prove that a
relayed sign-in, a proof for another host or purpose, and a swapped
password are refused, nothing changing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>
This commit is contained in:
Tizian 「ティツィアーン」 2026-10-20 21:20:12 +02:00
commit dab2c80524
Signed by: raisondetredev
GPG key ID: 07F6FCF405488B64
1 changed files with 966 additions and 137 deletions
Download patch file Download diff file Expand all files Collapse all files

8
packages/halkyon_base_server/README.md
View file

@ -194,7 +194,13 @@ Built on the three parts above, on the register (members forward every step thro
session. A setup never finished (never a confirmed authenticator) signs in with a code
mailed to the address it began with in its place (`request`, `code`), which calls off
a reset of the account waiting; any other account takes no code by mail there and
leaves it unused. SRP's identity I is the challenge's ID. An address nobody has (or whose
leaves it unused. SRP's identity I is `passwordIdentity`: the challenge's ID and the
host the device addressed (`host` on every proving call: in production it must be the
server's `apiServer.publicHost`, else `otherInstance`; in development any, as an
emulator reaches the machine as 10.0.2.2), so a hostile instance relaying a sign-in or
a phrase's proof here gets nothing taken; a member forwards its own host, and the
phrase's proof for a new password signs that password's digest
(`newPasswordDigest`). An address nobody has (or whose
account has no password) gets a salt and verifier from `signInDecoyKey` and the
address's hash, the same queries and arithmetic, and the same refusal: a wrong
password, an unknown address and a wrong, used or missing code are all