Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding note on handling online guessing attacks #456

Merged
merged 1 commit into from
May 29, 2024
Merged

Adding note on handling online guessing attacks #456

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 11 additions & 1 deletion draft-irtf-cfrg-opaque.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1893,7 +1893,9 @@ password as input to the OPRF. Furthermore, it is RECOMMENDED to incorporate
additions provide domain separation for clients and servers; see
{{security-analysis}}.

Finally, note that online guessing attacks (against any aPAKE) can be done from
## Handling Online Guessing Attacks

Online guessing attacks (against any aPAKE) can be done from
both the client side and the server side. In particular, a malicious server can
attempt to simulate honest responses to learn the client's password.
While this constitutes an exhaustive online attack, hence as expensive as an
Expand All @@ -1903,6 +1905,14 @@ In such cases, these online attacks are limited to clients and the authenticated
itself. Moreover, such a channel provides privacy of user information, including identity
and envelope values.

Additionally, note that a client participating in the online login stage
will learn whether or not authentication is successful after receiving the
`KE2` message. This means that the server should treat any client which fails to
send a subsequent `KE3` message as an authentication failure. This can be handled
in applications that wish to track authentication failures by, for example,
assuming by default that any client authentication attempt is a failure unless a `KE3`
message is received by the server and passes `ServerFinish` without error.

## Error Considerations

Some functions included in this specification are fallible. For example, the
Expand Down
Loading