Best Practices for Challenge/Response Authentication

Best Practices
for Challenge/Response Authentication
© 2014 Hitachi ID Systems, Inc. All rights reserved.

Contents
1 Introduction 1
2 Deﬁnitions 2
3 Uses for Challenge/Response Authentication 3
4 Equivalent Authentication Methods 4
5 Search Space, Degree of Randomness 6
6 Social Engineering 8
7 Standardized vs. User-Selected Questions 9
8 Usability 10
9 Privacy Protection 12
9.1 Encryption vs. Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.2 Assisted Service versus Self-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10 User Enrollment 15
11 Practical Example 17
11.1 Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.2 Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
APPENDICES 19
A Sample Questions 20
i

Best Practices for Challenge/Response Authentication
1 Introduction
This document introduces the concept of challenge/response authentication, where users are authenticated
by answering a series of personal questions. It then describes a number of best practices for robust, usable
deployment of challenge/response authentication techniques.
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

2 Deﬁnitions
An authentication factor is a form of evidence of a user’s identity. It is used by a human user to support
the claim that he is the legitimate owner of a login account.
Users may authenticate, typically in the context of a login process, using one or more of the following:
1. Something they know – i.e., a secret.
2. Something they have – i.e., a physical possession.
3. Something they are – i.e., a biometric sample.
Passwords and PINs are the most popular authentication technique and are an obvious example of “some-
thing a user knows.” Pass-phrases are another example, consisting of multiple words rather than a single,
short string of characters.
Challenge/response systems are another example of something a user knows. They typically consist of a
series of personal questions, where the user is expected to know the answer to each question. As with
all forms of authentication based on secrets, it is important that people other than the user in question not
know the answers to the user’s question.

3 Uses for Challenge/Response Authentication
Most computer systems authenticate users using passwords – i.e., users type a secret word or phrase,
which is compared against a stored value. Best practices for password management are beyond the scope
of this document. Interested readers can read more about this topic at:
http://Hitachi-ID.com/Password-Manager/docs/password-management-best-practices.html
Some systems may use alternate or supplementary authentication factors – biometric samples (voice print,
finger print, iris scan, palm print, etc.); one-time-password (OTP) tokens, smart cards, etc.
In either case, a business problem arises when users have difficulty using their primary authentication
method. Problems may include:
1. Forgotten passwords.
2. Inadvertently triggered intruder lockouts.
3. Expired passwords.
4. Lost or damaged OTP tokens or smart cards.
5. Malfunctioning or unavailable biometric sampling devices.
The problem that arises in each of these circumstances is a simple question: How does a self-service
system or an IT support analyst reliably authenticate an end user prior to providing assistance? Clearly
the primary authentication method cannot be used, since the user contacted the support organization or
accessed self-help infrastructure precisely because that method did not work.
Most organizations use challenge/response authentication to authenticate users prior to providing assis-
tance relating to their primary authentication method. The most common example of this is self-service
password reset, where a user:
1. forgets or locks out his password, and is therefore unable to login;
2. identifies himself;
3. authenticates himself by answering a series of personal questions;
4. is able to select a new password; and
5. can login again using the new password.

4 Equivalent Authentication Methods
When a user is able to use one authentication factor to manipulate another, a security equivalence is created
between the two factors. If one authentication factor is significantly stronger than the other, this equivalence
can weaken overall security.
This is best illustrated using an example:
1. An organization deploys strong password policies, including minimum length (8 characters), use of
many character classes (lowercase, uppercase, digits, punctuation marks), mandatory password
changes every 60 days, a long password history and composition rules blocking simple passwords,
such as dictionary words.
2. The same organization’s help desk authenticates users who forgot their password by asking them to
provide their mother’s maiden name and the last four digits of their social security number.
If an intruder wants to compromise a login ID in this organization, he may try to guess a password, but this
will be hard. He would have to find just the right password in a search space of about (26 + 26 + 10 + 32)8
,
or about 6 quadrillion (!) possible passwords. Even if he can guess a million passwords every second, this
would take about 96 years, on average.
A far easier approach would be to spend some time “off-line,” and find out the user’s mother’s maiden name
and social security number. A few phone calls should yield the former, and abuse of the social security
administration can yield the latter. With these two pieces of data in hand, the intruder can just call the help
desk, claim to be the victim, correctly answer the two questions and get a new password assigned. The
intruder can now access the user’s accounts.
Even a brute-force attack on these two pieces of data is much simpler. Assuming that the mother’s maiden
name is one of the world’s most popular 10,000 surnames, there are only 10 million possible combinations.
If a self-service password reset system is available and if it does not enforce intruder lockouts, an intruder
making 1,000 guesses per second could successfully authenticate and reset the victim’s passwords in about
1.5 hours, on average.
To summarize, by implementing a password reset business process using mother’s maiden name and last-
4-SSN, the organization has effectively reduced password strength from a search space of 6 quadrillion
possible passwords to one of 10 million possible responses – six hundred million times weaker!
The same effect applies whenever one authentication factor is used to verify user identity prior to manipu-
lating another authentication factor:
1. Synchronizing passwords.
2. Single sign-on.
3. Password reset.
4. Clearing or resetting token PINs.
5. Enrolling challenge/response profile data.

6. Enrolling biometric samples.
BEST
PRACTICE
Be sure to formulate a challenge/response policy whose strength is
comparable to the organization’s strongest password policy.
BEST
PRACTICE
If possible, combine challenge/response authentication with other
authentication factors, such as a one-time-password token or a biometric
sample.
Multiple authentication factors are always more secure than one.

5 Search Space, Degree of Randomness
In order to estimate the strength of a challenge/response system, one must estimate the number of possible
answers for each question.
Consider the following questions, and the estimated (or precise) number of possible answers for each one:
Question Assumptions Possible
answers
Mother’s maiden name http://www.last-
names.net/Articles/Strategies.asp
1,222 common
US surnames
Last 4 digits of SSN, credit card, phone,
etc.
10,000
Month/day of birth, employment, etc. 365
Month/year of birth, employment, etc. Assuming users between 20 and 80
years old
720
Make/model/year of first car Assuming 30 year time interval; 300
models/year
9,000
Favorite color Assuming most users choose a primary
color
10
City of birth Depends on how diverse the user
population is
50 – 500
Name of friend, spouse, child, etc.
http://www.lifesmith.com/comnames.html.
Note: very likely to be in top-100 for the
subject’s gender.
100
The probability of any given answer will vary based on parameters such as a user’s age, gender, ethnic
origin, etc. Some examples follow:
• In the US, mother’s maiden name has about a 1% chance of being Smith. A Vietnamese user is just
as likely to report Nguyen, and a Chinese user might just as frequently report Chan.
• City of birth depends on where users are physically located – it’s most likely to be the largest metro
area nearest the largest geographical concentration of users. Many users working in an organization
based in the US Midwest may report Chicago, for example.
• Choice of first car will likewise be impacted by location, as well as the user’s age (most Americans
purchase their first car in their teenage years) and relative popularity of models in the indicated time
period.
Just as the strength of a password policy may be estimated by combining the number of possible charac-
ters and raising the sum to the power of the password length (see below), so too the strength of a chal-
lenge/response policy can be estimated by multiplying out the number of possible answers to the available
questions:

PasswordStrength = (26uppercase + 26lowercase + 10digits + 32punct)8characters
(1)
PasswordStrength = 6, 095, 689, 385, 410, 816 (2)
ChallengeStrength = 1222q1 × 10000q2 × 10000q3 × 365q4 × 9000q5 × 10q6 × 100q7 × 100q8 × 500q9 (3)
ChallengeStrength = 20, 071, 350, 000, 000, 000, 000, 000, 000 (4)
This example illustrates that a well crafted challenge/response proﬁle can yield a search space as large as
that of a sound password policy.
BEST
PRACTICE
Include as many questions as feasible in the challenge/response proﬁle, to
maximize the search space.
BEST
PRACTICE
Estimate the size of the search space for each question.
BAD
IDEA
Avoid questions that have very few possible answers.

6 Social Engineering
In reality, password composition strength and challenge/response policy strength are not quite equivalent.
Careful research can yield answers to some of the questions in a challenge/response proﬁle, effectively re-
ducing the size of the search space for those questions to 1. In contrast, short of implementation problems,
no research will yield password character data.
To avoid this, it makes sense to take into consideration which of the questions in a set are vulnerable to
social engineering attacks and to discount the strength of those questions.
Some examples:
• Innocent-sounding phone calls may reveal a user’s mother’s maiden name and date of birth.
• Intercepting the user’s (postal) mail over a period of time can likewise reveal the last four digits of the
user’s social security number.
• Calls to the department of motor vehicles may expose the user’s driver’s license number.
Another problem with challenge/response proﬁles is that the data are typically constant. One’s date of birth
does not change over time, in the same way as a password might. This means that an intruder has more
time available to defeat the prompts.
These two problems – vulnerable individual questions and an open-ended time period – mean that a chal-
lenge/response policy should be constructed with a larger set of possible answers than the password it
protects.
BAD
IDEA
Avoid questions that have easily-guessed answers.

7 Standardized vs. User-Selected Questions
Some challenge/response systems use standard questions, while others let users choose their own ques-
tions and answer them. There are pros and cons to each approach:
Characteristic Standard Questions User-selected questions
Users are able to
provide answers to
every one of a set of
questions.
Poor. Some questions may simply
not apply (e.g., “what was your first
car?” does not apply to someone
who doesn’t drive).
Excellent. Users choose questions
they can answer.
Difficulty of guessing
answers
A known quantity – usually good. Random. Users often choose
questions that are easily
compromised.
Availability of questions
to intruders
Poor. By creating a new profile, an
intruder can see a full set of possible
questions.
Good. An intruder does not
necessarily know, a-priori, what his
victim’s questions may be.
The contrasting characteristics of these two approaches lead to some best practices:
BEST
PRACTICE
Use both standard and user-selected questions.
Standard questions are used because they are difficult to compromise. Unfortunately, an intruder willing to
spend lots of time may spend that time researching answers, and may compromise the standard question
profile.
User-selected questions are used because the questions themselves are difficult to guess, so a-priori re-
search of answers is impossible. This leads to the next best practice:
BEST
PRACTICE
When authenticating users, ask the standard questions first and only present
the user-defined questions after the standard ones have been correctly
answered.
This protects the user-selected questions from a researching intruder.
In general, it is wise to serialize questions to some degree, in order to obscure subsequent questions from
intruders faced with an initial prompt.

8 Usability
When designing a challenge/response system, it is important to consider usability. In practice, this means
allowing for several factors:
1. Memorable:
It is important to ask questions whose answers users remember. There is no point asking a user to
answer an obscure question, if the user will either be unable to answer or answer differently every
time.
2. Brief:
Users are impatient, and will not willingly enroll or answer too many questions.
3. Approximate:
Users are often poor typists, and will answer the same question using differently-spelled variations of
the same answer on different occasions.
4. Constant:
The answers to some questions may change over time. For instance, a user’s favorite movie, actor or
book may change over time. Since a significant time span may elapse between profile enrollment and
use of the profile for authentication, it makes sense to minimize use of such questions and instead
focus on questions that have concrete answers.
These considerations lead to some practical best practices:
BEST
PRACTICE
Make sure that questions in the challenge/response profile are easily
answered by the intended user and simultaneously hard to answer by anyone
else.
BAD
IDEA
Never change the text of a question once it has been deployed and users
have enrolled answers. This could create a mismatch between the new
question text and answers in user profiles, creating problems when users try
to authenticate.
BEST
PRACTICE
During the authentication process, don’t ask the user to answer more than 6
or 7 questions.
BEST
PRACTICE
During enrollment, don’t ask the user to populate more than 10 or so
questions.
BEST
PRACTICE
Do encode secret answers in manner that allows for approximate matching of
responses. Allow for answer validation even if the authentication answer
differs from the profile data by spaces, capitalization or the odd spelling
mistake.

BEST
PRACTICE
Do ensure that every question is a complete sentence, rather than a short
phrase. This makes translations easier.

9 Privacy Protection
Most jurisdictions require organizations to protect the privacy of their employees and customers – i.e., of
both internal and external users. Privacy protection is often defined as preventing unwarranted release of
any personally identifiable information (PII), and challenge/response profiles do often contain PII.
When designing a challenge/response system, it therefore makes sense to:
BEST
PRACTICE
Never display answers, only verify questions.
BEST
PRACTICE
Encrypt all sensitive data – especially answers to personal questions.
BEST
PRACTICE
Protect the server(s) on which this data is stored.
BEST
PRACTICE
Use a closed system, designed for data protection, rather than a directory,
designed for data publication.
BEST
PRACTICE
Lock out a profile after too many failed authentication attempts.
Intruder lockout for challenge/response profiles should work just like intruder lockout for passwords – pre-
venting an intruder from submitting a large number of guessed answers in a short time. Users do make
typing mistakes, so the intruder lockout interval can be high in terms of human guesses while still block-
ing automated attacks. For example triggering a lockout after 10 failed attempts in a 10 minute interval is
reasonable.
9.1 Encryption vs. Hashing
Encryption refers to a reversible process of protecting sensitive data. In a symmetrical encryption system,
data is scrambled using an algorithm that requires a key (the encryption key), and can only be unscrambled
(decrypted) using the same key.
In other words, the security of an encryption system depends on how well the encryption/decryption key is
protected.
Hashing refers to a one-way process of mapping plaintext data to a scrambled string of characters. There
is, by definition, no way to convert the scrambled data (the hash) back to the original plaintext.
When designing a challenge/response system, the question of whether it is better to encrypt or to hash user
profile data often arises. Each approach has pros and cons:

Data protection Encrypt profile data Hash profile data
Can be compromised if both the key and scrambled data are
successfully compromised?
Yes No
Vulnerable to guessing attacks? Yes Yes
Supports approximate matching of stored profile data against
data entered during the authentication process?
Yes No
Put another way, encryption is preferable if usability is a key concern, since users are unlikely to answer
the same question in exactly the same way on multiple attempts. For example, when asking a user to type
her mother’s maiden name, she might type “Jones-Smith” in one instance, “Jones Smith” the next time,
“jones-Smith” a third time and so on. This example does not even bring spelling and typing mistakes into
the picture.
If the user’s profile data is (reversibly) encrypted, then the matching code can decrypt it at authentica-
tion time and apply various approximate matching algorithms (e.g., case insensitive, ignoring spaces and
punctuation marks and even sounds-alike) to validate the user input.
In contrast, using a hashing approach, if the user types an inexact answer, the result is simply an au-
thentication failure. This can have a devastating impact on the system’s adoption rate and consequently
substantially reduce the return on investment.
On the other hand, in the event that the system where challenge/response data is stored is seriously com-
promised, hashed data can only be compromised by a brute-force guessing attack, while encrypted data
can – sooner or later – be extracted by an intruder, since both the data and the key are present on the
system.
BEST
PRACTICE
In most deployments, total system compromise is quite unlikely, so encryption
is strong enough. Usability is always an issue, so hashing of user profile data
is usually undesirable.
9.2 Assisted Service versus Self-Service
If challenge/response profiles will be used for both self-service authentication, for instance in the context of
self-service password reset, as well as by help desk staff, for instance in the context of assisted password
reset, it is often helpful to use different data in each case.
BEST
PRACTICE
Use separate challenge/response profile to authenticate the same users in the
context of self-service vs. assisted service processes.
Using different challenge/response questions to support self-service and assisted processes can promote
the goal of privacy protection, since the use of PII can be limited to self-service only.
The security of assisted service is enhanced by authenticating support staff before allowing them to au-
thenticate callers to the help desk. Caller authentication data can be further protected by requiring the help
desk analyst to enter answers to user questions, rather than displaying them on the screen. An audit trail
adds accountability to this process as well.

If a help desk analyst successfully responds to a user service call, he will have access to part of a user’s
profile. So long as the user has a separate profile for self-service authentication, the help desk analyst
cannot subsequently, anonymously impersonate the user, since he never had access to the user’s self-
service authentication questions.
Separating question sets used for self-service and assisted service also makes it possible to ask users to
answer questions in the context of the self-service profile which would be inappropriate to answer, due to
compromise of user privacy, in an assisted service scenario.

10 User Enrollment
Challenge/response systems must get the answers to personal user questions somewhere. When a chal-
lenge/response system is first deployed, existing data may be inadequate (does not cover all users or too
easy to compromise). This situation leads to a need for user enrollment:
1. A subsystem is required to identify users who must enroll. Inside an organization, this may be as
simple as “every Active Directory user.” On an Extranet, this may be “every new user.”
2. A subsystem is required to prompt un-enrolled users to complete their profiles:
(a) It should not invite too many users at any one time. This could overload the e-mail (or other
invitation) system. Moreover, some fraction of the users will not understand the process, or want
to verify that the invitation is legitimate and will consequently call the help desk. Too many users
calling the help desk at one time would overwhelm the help desk.
(b) It should not invite any one user too often, even if that user does not respond. Too-frequent
invitations are perceived as nothing more than a nuisance.
(c) It should be able to force enrollment if a user has been invited many times, and failed to respond.
3. The enrollment system must authenticate users before allowing them to update their profile.
4. The enrollment system should collect more data than will be used in a single authentication attempt.
This makes randomization of the questions posed to users possible.
These ideas can be restated as best practices:
BEST
PRACTICE
Collect enough data from a user to support random question selection during
a subsequent authentication process.
BEST
PRACTICE
Employ an automated enrollment system, which invites users to complete
their challenge/response profile.
BEST
PRACTICE
Roll out invitations gradually (example: 1000 users per day), not all-at-once.
BEST
PRACTICE
Do not invite the same user too often (say no more than once weekly).
BEST
PRACTICE
Force users to enroll when they repeatedly ignores invitations to complete
their profile.
BEST
PRACTICE
Authenticate users prior to enabling them to see and update their profile.

BEST
PRACTICE
Use an existing authentication method – e.g., a current network password –
prior to enrollment.
BAD
IDEA
Never use a weak authenticator, such as a PIN, a non-expiring password or
an e-mailed secret, to authenticate users.
Using a weak authentication would make the entire system weak, since an intruder could break the initial
authentication, complete a challenge/response proﬁle and subsequently reset a user’s password. This also
leads to a corollary:
BEST
PRACTICE
Enroll users before they forget or lock out their password. Do not start
enrollment only after a user needs service. Users experiencing an
authentication problem cannot reliably authenticate themselves and are in no
position to complete their challenge/response proﬁle in a trustworthy manner.

11 Practical Example
Following is a practical example showing how a fictitious organization could combine many of the ideas
presented in this document:
11.1 Enrollment
Every user in the organization that has a login ID on Active Directory, and whose last login date is less than
30 days old (i.e., the account is not obviously dormant) is invited to complete a challenge/response profile:
1. Users are invited to enroll on Monday, Tuesday, Wednesday and Thursday. No user is invited on other
days.
2. Up to 500 users are invited to enroll daily.
3. Users are invited at most once per week.
4. Any user can volunteer to update their profile any time. The controls above only impact invitations.
5. Users whose profiles are incomplete and who are about to be sent a fourth invitation are instead
attached to a special AD security group called ForcedEnrollment. A group policy object (GPO) is
applied to this group to change their Windows shell from EXPLORER.EXE to a program that launches
a kiosk-mode web browser, where they must complete enrollment.
6. Users who complete their profiles are removed from ForcedEnrollment (if they were members) and
are not invited to enroll again.
11.2 Questions
Three sets of questions are enrolled:
1. Standard questions that users may be asked to answer during self-service authentication:
(a) Twenty questions are provided.
(b) Users are asked to answer at least eight.
2. Standard questions that users may be asked to answer when they call the help desk:
(a) Ten questions are provided.
(b) Users are asked to answer at least four.
3. User-defined questions:
(a) Users are asked to provide two question/answer pairs.

11.3 Authentication
When a user calls the help desk, they are asked to provide answers to a random 3 of the at-least-4 help
desk questions. The help desk analyst must type the answers that the user provides - they cannot see the
answers.
When a user accesses the self-service system, they must answer a random 5 of the at-least-8 self-service
questions. If they can do this successfully, they are subsequently presented with a second authentication
step, presenting both of the self-deﬁned questions.
In all cases, user answers are compared in a case-insensitive, punctuation-insensitive and spacing-insensitive
manner to stored, encrypted data. This allows users who are poor typists to successfully sign into the self-
service system.
In all cases, the system (not the user) chooses which questions to randomly select. This prevents an
intruder from choosing to answer questions to which he has acquired answers.
Ten consecutive authentication failures in the space of 30 minutes triggers an intruder lockout for 1 hour.
This blocks systematic guessing attacks by an intruder, without impacting most legitimate users.

APPENDICES

A Sample Questions
Following are a set of sample questions that can be used to authenticate users. Users should be instructed
to only answer questions if they are confident the answers will never change.
Sample security questions, which may have alpha-numeric questions and so are suitable for a text user
interface, include:
• Which bank branch do you live closest too?
• What car do you wish you owned?
• What is your favorite food?
• Who is your favorite book character?
• What is your favorite game or sport?
• What is your favorite movie?
• What is your favorite pizza topping?
• What is your favorite restaurant?
• What is your favorite season of the year?
• What is your favorite sports team?
• In which department did you first work?
• What was your first position in the company?
• What was your first car?
• Who is the person you admire the most?
• What was the most memorable day in your life?
• Who was your childhood hero?
• What is the nickname of your sibling?
• Who was your first boss?
• What award are you proudest of?
• What city were you born in?
• What is the farthest from home you have traveled?
• What is the name of the first school you attended?
• What is the name of the first person you were romantically interested in?
• What is your astrological sign?
• What is your father’s middle name?
• What is your mother’s’ middle name?
• Who is your favorite actor, actress or celebrity?
• What is your favorite musical band?
• What is your favorite beverage?
• What is your favorite board game?
• Who is your favorite book character?
• What is your favorite dessert?
• What is your favorite hobby or pastime?
• What is your favorite ice cream topping?
• What is your favorite song?
• What is your favorite television show?
• What is your favorite vacation spot?
• What is your mother’s maiden name?
• What is your place of birth?
• What is your school team’s mascot name?
• What was the breed of your first pet?
• What was the color of your first automobile?

• What were the make and model of your first car?
• What was the name of a favorite childhood pet?
• What was the name of your first girlfriend/boyfriend?
• What was the street name of your childhood home?
• What was your favorite toy when you were a child?
• What did you do on your first job?
• What was your first phone number as a child?
• What year did you purchase your first car?
• What was the name of your first pet?
• Who is your favorite politician?
• Who is your most disliked politician?
• Who is a famous, living person you would most like to meet?
• Who was a famous, now deceased person you would have liked to meet?
• Who is your favorite artist?
• Who is your favorite author?
• With whom did you share your first romantic kiss?
• Who was your favorite elementary school teacher?
The following questions may also be used. They differ from the above in that they have numeric answers,
making them suitable for use with a telephony-based solution that uses touch-tone input:
Sample security questions, that have numeric answers and so are suitable for authentication using a touch-
tone phone, include:
• What is your favorite radio station (number on the dial - NNNN)?
• In what year did you start with your company?
• On what date were you hired?
• What is your parents’ wedding anniversary date?
• Type a significant date in your life (YYYYMMDD)?
• What are the last 4 digits of your SSN?
• What are the last 4 digits of your home phone?
• What is a birth date of a family member?
• What is a relative’s telephone number that is not your own?
• What is the date of your anniversary [mm/dd/yyyy]?
• What is the mileage distance you live from your furthest relative?
• What is your Country or employee identification number?
• What is your date of birth (MM/DD/YYYY)?
• What is your driver’s license number?
• What is your favorite dial number of radio station?
• What is your favorite or lucky number?
• What is your passport number?
• What is your social security number?
• On what year you will be eligible to retire?
www.Hitachi-ID.com
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
File: /pub/wp/documents/bp-challenge-response/best-practice-challenge-response-
Date: 2007-05-21

Best Practices for Challenge/Response Authentication

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (8)

Mais de Hitachi ID Systems, Inc.

Mais de Hitachi ID Systems, Inc. (20)

Último

Último (20)

Best Practices for Challenge/Response Authentication