We need, at the minimum, a way to define replication collision strategies based on content values. In one case, for instance, we are replicating an OTP counter. This counter should never decrement, so the highest value should always be considered the correct value when a replication collision occurs.
It would additionally be very handy to have a plugin infrastructure for this. It would also be very nice to specify the configuration for replication strategies in the schema for the attribute.
It will be very hard to implement this in general, and it would contradict replication design where latest update should win. Regarding the specific case of a counter going backward, is this a general concern that it could happen or is there a test scenario to trigger this - then we should investigate why it happens
This is a general concern that is probably justified by the volatile nature of an OTP counter. It will be written on every login and MUST NOT ever go backwards. If the counter is decremented, it means that one time passwords are no-longer one time guaranteed. Give the high frequency of writes, generating an increase in replications, it is statistically far more likely that a collision may send the OTP counter backwards.
This is also a potential attack vector. If a malicious user were to obtain a block of token codes, it would be possible to attack replication via simultaneous logins to force the counter to the beginning of the block. This would effectively make the block infinitely usable and defeat the authentication system.
The above is theoretical, but that the consequences are very bad if a practical exploit could be devised.
As already stated in comment #3, this is cannot be achieved by the current design. In my understanding OTP has found an other solution, so I'll close as wontfix. We can address specific new requests if needed
Metadata Update from @npmccallum: - Issue assigned to lkrispen - Issue set to the milestone: 1.3.4 backlog
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1092
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Invalid)
Login to comment on this ticket.