Require plugins to be responsible for locking

Problem/Motivation

Prior to 8.x-1.3 no locks were utilized as part of the login process.

It was discovered that the current usage of alreadyAcceptedCode()/storeAcceptedCode() outside of a locked run allows for a possible replay attack due to a race condition.

The TOTP/HOTP timeslice/counter checks are also at risk to these attacks and are another example of plugin code that should be inside a lock.

Temporary global locking has been put in place to protect against these scenarios, however there are times when this locking is unnecessary (such as tfa_vault_totp) and could pose an additional risk of delaying a login for a user. As such we should make this a requirement for plugins to implement.

This is an API spec change and as such can not be applied to 1.x, the global lock must remain in 1.x.

Steps to reproduce

N/A

Proposed resolution

• Remove lock creating from EntryForm
• Create CR indicating new requirement for ecosystem modules
• Add notes to API methods that they should be called inside a lock

Remaining tasks

Patch
Create CR.

User interface changes

None

API changes

Plugins will now be responsible to obtain a lock when required for validating previously accepted codes.

Data model changes

None