Confirmed users
471
edits
(talk about anonymous server-side data) |
|||
| Line 321: | Line 321: | ||
== Protecting the | == Protecting the storage selection index == | ||
I think we can tolerate a "TOFU" (Trust On First Use) setup step, especially | I think we can tolerate a "TOFU" (Trust On First Use) setup step, especially | ||
| Line 333: | Line 333: | ||
To accomplish this, nothing in the post-setup messages should give an | To accomplish this, nothing in the post-setup messages should give an | ||
attacker a way to brute-force the password | attacker a way to brute-force the password (reserving that "power" for the | ||
storage server. This precludes the use of anything that is derived from the | storage server), including the field that tells the server which database row | ||
password, leaving us with two choices: | to use. This constraint precludes the use of anything that is derived from | ||
the password, leaving us with two choices: | |||
* the non-secret email addres | * the non-secret email addres | ||
| Line 342: | Line 343: | ||
The first choice loses the "anonymous data" property on the server. The | The first choice loses the "anonymous data" property on the server. The | ||
second choice loses the server's ability to do per-user rate-limiting of | second choice loses the server's ability to do per-user rate-limiting of | ||
online guessing attacks. I'm still trying to decide which is more important, | online guessing attacks (but retaining other tools, like per-IP-address | ||
or if there is some clever way to achieve both. | limiting of non-distributed attacks). I'm still trying to decide which is | ||
more important, or if there is some clever way to achieve both. | |||
== Protocol Diagram == | == Protocol Diagram == | ||