Confirmed users
110
edits
mNo edit summary |
|||
| Line 12: | Line 12: | ||
* When persona authentication is performed both the client and server keep a hash of the assertion | * When persona authentication is performed both the client and server keep a hash of the assertion | ||
** [dchan] - Is a hash of the assertion needed? Is this an implementation detail to make sure the assertion is the proper size for keying the algorithm? | |||
* That hash is then used as seed for a HOTP or TOTP, a different token is sent on each request. | * That hash is then used as seed for a HOTP or TOTP, a different token is sent on each request. | ||
** [dchan] - Should we add in some additional random / session data to prevent two identical assertions from generating the same HTOP sequence? I don't think it matters in practice since the expiration time /should/ be different for each generated assertion. The concern being if some bad implementation always set the assertion expiration time to the same e.g end of year. | |||
* Clients will send the correct HOTP, the server will compare its token using the seed. | * Clients will send the correct HOTP, the server will compare its token using the seed. | ||
What to do about anonymous? | What to do about anonymous? | ||
** [dchan] - Captcha may be sufficient. The UX likely isn't ideal in this case. | |||
=== Non-Persona clients === | === Non-Persona clients === | ||