Confirm
471
edits
Changes
→Resetting the Account: update examples: don't send kA to server
resetAccount() needs request confidentiality, since the arguments include the newly wrapped kB value and the new SRP verifier, both of which enable a brute-force attack against the password. HAWK provides request integrity. The response is a single "ok" or "fail", conveyed by the HTTP headers, so we do not require response confidentiality, and can live without response integrity.
So the single-use resetToken is used to derive three values(shown with their sample values):
* tokenID: 52437066aae511d3 3709bf25dc6a682a 7e943d49d94c84b3 4e1e6b11c9913159* request HMAC key: 7de6c9b102dac62f 81d3a09baa00523d e7170ff17238b3af 8491e4cfb23e1a88* request XOR key: 82d447f095aa8023 3eb5cb5d6c4eea25 5857809b6326b6bd 55fab2d3498b1cf8 a31bb0e319d7c0dc 2792740a480c1a98 99c1a6328bc2066e 3ecc9e8079ae8af6 046f15f3a586bfb3 b9908de7cd60b504 44fdfacc3cf32e2b efc72fca9063e28d a815989f86223394 b89db34bffdc94bb 68c05a49d1f1f63a 2c463d335a06c007
The request data is XORed with requestXORkey, then delivered in the body of a HAWK request that uses tokenID as credentials.id and requestHMACkey as credentials.key . Note: it is critical to include the request body in the HAWK integrity check (options.payload=true, on both client and server), otherwise a man-in-the-middle could substitute their own SRP verifier, giving them control over the account (access to the user's class-A data, and a brute-force attack on their password).
[[File:PICL-IdPAuth-encryptResetAccount.png|Encrypting the resetAccount Request]]
In our example, the XORed ciphertext is:
c29505b3d1efc664
76fc81162003a46a
0806d2c83773e0ea
0da3e88815d642a7
03ba1240bd72667b
8f3bdea1e4a1b437
297014813f77b0d9
8675243bc5133449
c4aed73061437974
7159472c01ad7bcb
942c281fe826f8fc
371ef5114cbe3c52
48f47a7c62c7d573
507459a013317a54
9831a8ba250400cd
d4bfc7c8a6fb3ef8
= Creating the Account =
