Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Alessandro Campi is a
technical officer at the
Banking Supervision
Department of Banca dItalia
(Italian Central Bank). Campi
works in IT risk in the banking
sector, taking part in technical
working groups at both the
local and European levels.
Coming from the software
industry, he formerly served
as an IT internal auditor and
contributed to develop IT
security policies and IT risk
analysis frameworks.
Do you have
something
to say about
this article?
Visit the Journal
pages of the ISACA
web site (www.isaca.
org/journal), find the
article, and choose
the Comments tab to
share your thoughts.
Go directly to the article:
42
Implementations in Use
Having outlined the fundamental requirements of a strong
authentication solution, this article will now discuss common
cases of implementation to determine whether they meet
the standards for strong authentication. In some cases, the
article highlights (see items one to four of the following list)
implementation mismatches with respect to the proposed
independence and quality characteristics. In other cases
O
3
3 (1)
3 (2)
3 (2)
3 (1)
3 (1) (2)
3 (1)
Note
43
(see items five and six), there are some possible vulnerabilities
to be taken into account. The following list does not include
the use of inherence factors since they are not widespread
allegedly due to drawbacks and other inconveniences4:
1. The use of a password plus a grid cardSince a grid card
can be easily replicated, it cannot be considered a viable
ownership factor. In addition, legitimate users in general
have no way to detect if fake copies of their cards have
been made, thus they will continue using the system at the
same time as the fraudster.
2. The use of a password plus a secret stored on the access
device (e.g., software digital certificates, smartphone
applications, embedding authentication codes)As
long as secrets stored in the AD can be surreptitiously
stolen via the Internet (e.g., through the use of malware)
and used many times by the fraudster, their use together
with the user password cannot be considered a sound
implementation of strong authentication.
3. A hardware token-generating OTP to be used together
with the IU customer identifier (e.g., banking account
number)Since a customer identifier is not designed and
managed to be known only by the legitimate user, this is
a single-factor solution and, as such, it does not provide
strong authentication.
4. A PIN-protected card used together with a card reader
to obtain a OTP to access the SP siteIn this case, a
knowledge factor and an ownership factor are used, but
the first PIN is used only to enable the card reader and
only the OTP is transmitted to the verifying entity (the
SP); therefore, a possible vulnerability of the OTP would
affect the security of the whole solution, likely setting aside
the protection offered by the PIN. As a result, since the
security of the knowledge factor is dependent on that of
the ownership, this case should not be regarded as a strong
authentication solution.
5. The use of a password plus an OTP generated and
transmitted to the SP by an application stored on the IUs
mobileSince the OTP is generated and transmitted via a
second channel, this arrangement bears the features needed
to provide strong authentication. However, viruses have
been detected that are able to transmit from a smartphone
to a PC (or vice versa) when they are connected (e.g., to
synchronize their data). Therefore, specific measures to
strengthen the independence of the two channels should
44
Figure 2Formula
Endnotes
In spite of extensive use in the IT security sector, the notion
of strong authentication has not been standardized yet in
the security literature. For a basic definition, see Federal
Financial Institutions Examination Council (FFIEC),
Authentication in an Internet Banking Environment, and
FAQ, 12 October, 2005 and 15 August, 2006.
45