Confirmed users
471
edits
(add a glossary) |
(→Resetting the Account: update examples: don't send kA to server) |
||
Line 384: | Line 384: | ||
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. | 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: | So the single-use resetToken is used to derive three values (shown with their sample values): | ||
* tokenID | * tokenID: 52437066aae511d3 3709bf25dc6a682a 7e943d49d94c84b3 4e1e6b11c9913159 | ||
* request HMAC key | * request HMAC key: 7de6c9b102dac62f 81d3a09baa00523d e7170ff17238b3af 8491e4cfb23e1a88 | ||
* request XOR key | * request XOR key: 82d447f095aa8023 3eb5cb5d6c4eea25 5857809b6326b6bd 55fab2d3498b1cf8 a31bb0e319d7c0dc 2792740a480c1a98 99c1a6328bc2066e 3ecc9e8079ae8af6 046f15f3a586bfb3 b9908de7cd60b504 44fdfacc3cf32e2b efc72fca9063e28d a815989f86223394 b89db34bffdc94bb 68c05a49d1f1f63a 2c463d335a06c007 | ||
[[File:PICL-IdPAuth-resetAccount.png|Deriving the resetAccount Keys]] | |||
The request data will contain wrap(kB), a new (randomly-generated) SRP salt, and the new SRP verifier, all concatenated together. Since we always pad the SRP verifier to the full (256-byte) group length, all four pieces are fixed-length. We generate enough reqXORkey bytes to cover all four values. In our example, the concatenated plaintext is as follows: | |||
4041424344454647 | |||
48494a4b4c4d4e4f | |||
5051525354555657 | |||
58595a5b5c5d5e5f | |||
a0a1a2a3a4a5a6a7 | |||
a8a9aaabacadaeaf | |||
b0b1b2b3b4b5b6b7 | |||
b8b9babbbcbdbebf | |||
c0c1c2c3c4c5c6c7 | |||
c8c9cacbcccdcecf | |||
d0d1d2d3d4d5d6d7 | |||
d8d9dadbdcdddedf | |||
e0e1e2e3e4e5e6e7 | |||
e8e9eaebecedeeef | |||
f0f1f2f3f4f5f6f7 | |||
f8f9fafbfcfdfeff | |||
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). | 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]] | [[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 = | = Creating the Account = |