All types of functionality should provide be as similar as possible across all delivery channels (e.g. phone, web e-commerce, mobile) and also when there are alternative versions for accessibility reasons (e.g. device constraints, user ability, environmental conditions). This is especially true for security controls where a weakness in one channel could undermine the security of all channels.
For example in authentication, either utilising passwords or some other method of validating identity such as certificates or one-time tokens, it must not be possible to bypass the controls altogether. Nor should it be possible to circumvent a security control in one channel, or mode, that is required in another. All channels should have an equal degree of protection.
This was recently highlighted in a description of how the well-used reCAPTCHA could be broken by a weakness in the alternative audio version. Many sites use the service to help prevent automated submissions of data such as for user registration, feedback, enquiries, and even limit higher-rate usage of a site.
The attack against the audio version, which output six spoken words and masked them with background noise from static-laden radio broadcasts backwards, relied on the finding that the background noise did not include high sound frequencies, and thus it was possible to extract the words for analysis. The attacker's clever analysis was made slightly easier in that they found reCAPTCHA accepted multiple spellings of the solutions for some phonetically-similar words, making the problem easier to solve. The issue has since been addressed.
So check those web sites, alternative versions, administrative interfaces, mobile apps and anything else that shares the same users.
Posted on: 06 July 2012 at 08:45 hrs