Currently a time-based OTP can be used multiple times as long as it's still valid. This is incorrect according to RFC 6238 (http://tools.ietf.org/html/rfc6238#section-5.2):
Note that a prover may send the same OTP inside a given time-step window multiple times to a verifier. The verifier MUST NOT accept the second attempt of the OTP after the successful validation has been issued for the first OTP, which ensures one-time only use of an OTP.
Steps to reproduce: 1. As admin, create a new user with a password. 2. Enable OTP authentication for this user. 3. Create TOTP token for this user with long enough interval (e.g. 1 minute). 4. Logout. 5. As soon as the OTP changes in the token, login as the user. 6. Reset the password with the same OTP. 7. Relogin with the same OTP.
Actual result: The same OTP can be used multiple times.
Expected result: In step #6 and #7 the user should not be able to reuse the same OTP.
I have been thinking a bit about this issue, and I want to drop a possible partial solution that is not perfect but could be a start.
The main reason why we do not prevent repeated validations is that writing to the LDAP tree to keep state would cause a lot of replication messages to be fired all the time and that is unwelcome.
However we can at least prevent validation on the same server. We can keep a memory buffer which records and blacklist used token numbers in the last X seconds. Ideally this buffer is just a hash table indexed by token-id/code and contains an expiration timestamp, once the entry is expired it can be overwritten as the code will not be considered valid anwyay even if reuse is attempted.
In order to extend this method to multiple servers we'd need a shared hash table with locking. That's something we can look at for the future, but not feasible right now.
TOTP token has to have a high water mark attribute (HWM). This attribute needs to be updated regardless of whether we replicate it or not preventing token reuse on the same server so the proposal above is not needed. AFAIR remember we discussed this on the list and agreed that the counter and HWM should be replicated and we need a clear instruction of how to turn this replication off if deployment sees a performance issue.
We decided to at least prevent multiple use of the same token on the same FreeIPA server. Designing discussion how to prevent it across all servers will happen soon.
https://www.redhat.com/archives/freeipa-devel/2014-July/msg00205.html
master:
ipa-4-1:
ipa-4-0:
Metadata Update from @edewata: - Issue assigned to npmccallum - Issue set to the milestone: FreeIPA 4.0.1
Login to comment on this ticket.