CS 411W Lab II
Prototype Product Specification
For
CertAnon
Prepared by: David Mirra, Red Group
Date: 11/04/2007
Mirra 11/04/2007
Table of Contents
1
Introduction ................................................................................................................. 1
1.1
Purpose................................................................................................................ 1
1.2
Scope ................................................................................................................... 5
1.3
Definitions, Acronyms, and Abbreviations ........................................................ 6
1.4
References ........................................................................................................... 8
1.5
Overview ............................................................................................................. 9
2 General Description .................................................................................................... 9
2.1
Prototype Architecture Description .................................................................. 10
2.2
Prototype Functional Description ..................................................................... 12
2.3
External Interfaces ............................................................................................ 16
3 Specific Requirements .............................................................................................. 18
3.1
Functional Requirements .................................................................................. 19
3.2
Performance Requirements ............................................................................... 22
3.3
Assumptions and Constraints ............................................................................ 23
3.4
Non-Functional Requirements .......................................................................... 25
4 Appendix ................................................................................................................... 26
4.1
Formal Resource Request Document................................................................ 26
List of Figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
Figure 7.
Major functional component diagram ................................................................ 3
Phase 1 prototype major functional component diagram................................. 10
CertAnon prototype token setup process flow. ............................................... 13
CertAnon prototype partner site account association process flow ................ 14
CertAnon prototype partner site authentication process flow ......................... 15
Site map of the CertAnon website .................................................................. 17
Site map for the partner websites .................................................................... 18
List of Tables
Table 1. Feature comparison between full product and prototype................................... 12
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements ....... 23
ii
Mirra 11/04/2007
1 Introduction
Fraud and identity theft struck 8.9 million victims in 2006. Total annual losses jumped
by $2.2 billion from 2005 to 2006, and the mean resolution time per incident skyrocketed from
28 to 40 hours per victim (VeriSign, n.d.). One of the main tools in the arsenal of identity
thieves is phishing, the practice of spoofing e-mail and websites of consumer businesses in order
to trick users into divulging information such as usernames and passwords. According to the
Anti-Phishing Working Group, a record high 55,643 unique phishing sites were identified in
April 2007 (APWG, n.d.). Account credentials may also be disseminated through theft by
insiders or through corporate network intrusions.
Such crimes are occurring more frequently as Internet users move more and more of their
lives online with only passwords to protect them. Online services such as banking, stock
trading, shopping, and travel planning are all account-based activities that are commonly
protected by passwords. This single-factor authentication method is easily compromised and
endangers the security of online accounts. Passwords are insecure, difficult to manage, and
increasingly vulnerable to fraud.
1.1 Purpose
CertAnon is an anonymous Wide-Area Network (WAN) authentication service conceived
by the Old Dominion University (ODU) CS410 Red Group. It is designed to replace the
password, the weak link in online account authentication, with an enterprise-grade two-factor
1
Mirra 11/04/2007
authentication solution that is available to the everyday Internet user. It can be integrated with
any account-based web portal to provide an instant security boost for a site's customers. It
utilizes available, affordable, and proven technology within an innovative and scalable
framework. CertAnon targets the large and growing markets of individual Internet users and
security-conscious businesses, and it offers clear benefits to both.
Two-factor authentication combines something a user knows, such as a short personal
identification number (PIN), with something in the user's possession. In the case of a CertAnon
user, that something will be a SecurID token produced by RSA, the security division of EMC
Corporation. Carried as a key fob, it generates a new pseudo-random number on a digital display
every 60 seconds. When logging into an account that uses two-factor authentication, a user
enters his PIN followed by the token code currently displayed on the token. This combination
produces a unique one-time-use passcode that is then transmitted to a remote authentication
server. At any given time, the authentication server can predict the number that appears on a
token. This allows the server to confirm that the user knows the correct PIN and also possesses
the proper token. These two factors together provide a much higher level of security than a
password alone.
Many companies use this RSA product to secure their internal networks, and some banks
and brokerages provide SecurID tokens to customers for use when accessing online accounts.
Currently, many individual Internet users are reluctant to use such proprietary systems because
each token only works with the account that provided it. The innovation that CertAnon provides
is the ability to leverage a single token across multiple participating online accounts. A user may
associate a token with any account that offers CertAnon authentication. Only one PIN needs to
be remembered instead of a different password for each site. The fact that the server will only
2
Mirra 11/04/2007
accept a given token code one time reduces the viability of phishing and keylogging attacks,
providing greater security for user accounts. Also, no personal information will be collected
during the token registration process. Maintaining virtual anonymity reduces the threat of data
theft and offers users a high level of personal privacy.
Figure 1. Major functional component diagram
Figure 1 illustrates the major functional components of the CertAnon service. It
identifies four major functional pieces. The first is the RSA SecurID token possessed by an
Internet user. This token, pictured in the upper left of Figure 1, will be purchased from RSA and
offered for resale online.
The second functional piece is a series of synchronized authentication servers running the
RSA Authentication Manager software. When an incoming authentication request is received,
3
Mirra 11/04/2007
an authentication server determines if the provided time-sensitive passcode (PIN + token code) is
valid for the user's token. Requests can be sent to multiple authentication servers
simultaneously, and the first response received will be passed back to the requestor.
The third functional piece is the CertAnon website. This site will be written in PHP and
hosted on a private server. The site will include interfaces for token sales, token registration,
account maintenance, partner site registration and encryption key exchange, and authentication
module downloads. A MySQL database will be used to store user account information related to
each token and the associated partner site accounts. In order to preserve user anonymity, the
database will not record any personally identifying "real-world" information such as legal names
or street addresses.
Partner websites comprise the fourth functional piece of the service. They are
independent online businesses that incorporate free CertAnon software modules into their
websites. The modules will transmit login information from registered users to the CertAnon
authentication servers.
CertAnon will be targeted at two particular markets. The first customer base consists of
regular Internet users. Recent research indicates that there are 211 million consumers with
Internet access in the United States alone (MMG, 2007). A primary goal will be to capture 20%
of those within the next 10 years. International expansion would be a natural progression once
operations in the United States are stabilized. Revenue would be derived from token sales with
an anticipated unit price of approximately fifty dollars. If a critical mass of customers can be
built, CertAnon could become a must-have feature for online sites to offer. Marketing materials
will emphasize the increased security of the product in conjunction with the virtual anonymity of
the registration process.
4
Mirra 11/04/2007
The second target market is comprised of security-conscious online businesses.
CertAnon will sell batches of tokens that can be redistributed to their customers on request or as
part of a concerted push to all account holders. The low implementation cost per website and the
improved security for their customers will encourage these businesses to offer the CertAnon
service. Losses from fraud reimbursements can be cut significantly without the expense of a
costly proprietary system.
1.2 Scope
The prototype of the CertAnon service is designed to demonstrate the feasibility of using
a centralized two-factor authentication system with multiple independent users and multiple
independent partner websites. The first functional objective is to successfully demonstrate the
use of a middle tier, the CertAnon website, to extend the functionality of a two-factor
authentication solution across multiple independent partner sites. Two-factor authentication
credentials entered by an end user on a partner site must be linked to a particular token. These
credentials will be sent to the CertAnon website and cross-referenced against configured
accounts to identify the associated token. The token serial number and the passcode are then
sent to the authentication server for validation. The authentication response is passed back
through the CertAnon site and on to the partner site. It is this middle-tier innovation that allows
CertAnon to offer a solution that permits a customer to securely access all participating online
accounts using a single access method.
The second objective is to demonstrate the CertAnon service using a simulated hardware
token that does not require any client software. In order to highlight the ease of use and cross-
5
Mirra 11/04/2007
platform availability of this solution, it will be shown that the service is not limited to specific
client hardware or operating systems and that it needs no special software installed by the user.
Third, user registration and account maintenance will be handled in an anonymous
fashion while still providing strong account authentication. Account access must be limited to a
specific token holder without collecting or using personal information such as a real name, a
street address, or a credit card number. This feature will allay consumer fears of information
misuse or theft and attract additional customers who value the privacy that this provides.
The final objective is to show the ease of integration of this third party system with a
potential partner website. The aim is to illustrate the relative simplicity of incorporating a prebuilt PHP module into an existing site in order to offer the CertAnon service. A short and
straightforward integration process is an important aspect of the service and will be a valuable
selling point for commercial partners.
1.3 Definitions, Acronyms, and Abbreviations
Key fob: A decorative or functional item attached to a key ring or key chain, such as an RSA
SecurID token
Keylogging: The use of software or hardware to capture a computer user's keystrokes, also
known as keystroke logging
Load balancing: Tuning a network to evenly distribute data among available resources
MySQL: An open source multi-user database management system
Partner website: Any organization with an Internet presence that contracts to use CertAnon
technology for user authentication
6
Mirra 11/04/2007
Passcode: A type of password, often purely numeric. In the case of CertAnon, it is the
combination of a user selected PIN plus the pseudo-random token code provided by the
RSA token.
Perl: A high-level scripting language well-suited for process, file, and text manipulation
Phishing: The act of sending an e-mail to a user falsely claiming to be an established legitimate
enterprise in an attempt to scam the user into surrendering private information that will be
used for identity theft. The e-mail directs the user to visit a website where they are asked
to update personal information such as passwords and credit card, social security, and
bank account numbers. The website is a bogus site designed to capture this user
information for purposes of identity theft or other financial fraud.
Personal Identification Number (PIN): A personal identification number normally used to secure
a user account
PHP: A server-side programming language designed for building dynamic web pages
Proprietary system: A system that is used, produced, or marketed under exclusive legal right of
the inventor, maker, or operator
Pseudo-random: Being or involving entities (such as numbers) that are selected by a definite
computational process but that satisfy one or more standard tests for statistical
randomness
RSA: The security division of EMC Corporation, a provider of corporate information
infrastructure technology and solutions
RSA SecurID: A two-factor authentication solution offered by the company RSA
RSA Authentication Manager: Server-side software by RSA used to verify authentication
requests and centrally administer authentication policies for enterprise networks
7
Mirra 11/04/2007
Single-factor authentication (SFA): The traditional security process that requires a user name
and password before granting access to the user
Token: A physical device that an authorized user of computer services is given to aid in
authentication, also known as a security token, hardware token, authentication token or
cryptographic token
Transmission Control Protocol/Internet Protocol (TCP/IP): A suite of protocols designed for
enabling communications over interconnected networks. It is a core technology for
Internet communications.
Two-factor authentication: A system of which the user provides dual means of identification,
one of which is typically a physical token, such as a key fob, and the other of which is
typically something memorized, such as a security code
Wide-area network (WAN): A telecommunications network with linked segments spread across
a wide geographic area
1.4 References
Anti-Phishing Working Group. (n.d.). Anti-Phishing Working Group. Retrieved September 15,
2007, from http://www.antiphishing.org/.
Miniwatts Marketing Group. (2007). America Internet usage and population statistics.
Retrieved September 17, 2007, from http://www.internetworldstats.com/stats2.htm.
Mirra, David. (2007). Lab 1 – CertAnon Product Description. Reston, VA: Author.
RSA. (2007). RSA SecurID. Retrieved September 17, 2007, from
http://www.rsa.com/node.aspx?id=1156.
8
Mirra 11/04/2007
VeriSign. (n.d.). Online fraud stats - how safe is your e-commerce experience? Retrieved
September 17, 2007, from
http://www.verisignsecured.com/content/Default.aspx?edu_stats_body.html.
1.5 Overview
This product specification provides the hardware and software configuration, external
interfaces, capabilities and features of the CertAnon prototype. The information provided in the
remaining sections of this document includes a detailed description of the hardware, software,
and external interface architecture of the CertAnon prototype; the key features of the prototype;
the parameters that will be used to control, manage, or establish these features; and the
performance characteristics of these features in terms of inputs, outputs, and user interaction.
2 General Description
The prototype of the CertAnon service will focus on the innovative design of a
centralized two-factor authentication system with multiple independent users and multiple
independent partner websites. Some aspects of the full service which are already in wide
practical use, such as certain standard website features, will not be simulated due to time and
budget constraints.
9
Mirra 11/04/2007
2.1 Prototype Architecture Description
Figure 2. Phase 1 prototype major functional component diagram.
Figure 2 illustrates the major functional components of the CertAnon prototype and the
flow of data between them. It simplifies the components shown in Figure 1 but retains the basic
innovative functionality. In the prototype, the token will be simulated by a hard copy list of
token serial numbers and 20-50 related token codes per serial number. An ODU desktop
personal computer (PC) with Internet access and a web browser will be used to access the
CertAnon website and partner websites.
The authentication servers running the RSA Authentication Manager software will be
simulated in the prototype by a Perl script running on an ODU web server. This script will be
listening on a pre-defined port for authentication requests. It will utilize a MySQL database to
10
Mirra 11/04/2007
store the same list of token serial numbers and related token codes given to the test user. It will
also store the PIN chosen for each token by the user. The pre-defined token codes will serve to
emulate the concurrent token code calculations of the RSA product while sidestepping
complicated problems such as clock synchronization that lie outside of the innovative aspects of
the CertAnon service. When an incoming authentication request is received, the authentication
server will check the database to determine if the provided passcode (PIN + token code) is valid
for the given token serial number. If a correct passcode is provided, the token code that was used
is flagged so that it cannot be used again. The one-time-use passcode feature of the full RSA
product is thus maintained in the prototype.
The CertAnon website will be written in PHP and hosted on an ODU web server. It will
utilize a MySQL database to store user account information. The prototype site will only include
interfaces for token registration and account maintenance by end users. It will also function as a
middle tier between the partner sites and the authentication server. Incoming authentication
requests will be associated with a token serial number based upon the partner site domain and the
username. This information is then forwarded to the authentication server for validation.
Authentication responses will be transmitted back to the requesting partner site.
Partner websites comprise the fourth functional piece of the service. The prototype will
include two simulated partner sites written in PHP and hosted on an ODU web server. They will
incorporate the plug-in module to transmit login information from registered users to the
authentication server script. Each site will have a simple MySQL database to store account
information.
Table 1 provides a summary of the differences between the full CertAnon service and the
prototype discussed above.
11
Mirra 11/04/2007
Features
Real World Project
Prototype
Token
RSA SecurID key fob
Hard copy list of 20-50 valid token codes for
several token serial numbers
Client Computer
Any PC with Internet access
Lecture room PC with Internet access and a
and a web browser
web browser
Hosted on an independent web Hosted on an ODU server; Consists of
server; Consists of interfaces for interfaces for token registration and account
token sales, token registration, maintenance
account maintenance, partner
site registration, encryption key
exchange, authentication
module downloads
CertAnon website
Authentication server
Four dedicated servers running
RSA Authentication Manager
software provide redundancy in
case of hardware failure or
other outage
Partner website
Any independent website
Two simulated PHP websites hosted on the
incorporating the authentication
ODU web server and configured to use the
modules to offer CertAnon
authentication module with pre-registered user
authentication to its users
lists
Authentication modules
Plug-in modules developed for One PHP module incorporated into the two
several popular technologies
simulated partner sites
(PHP, .NET, etc) and made
available for free on the
CertAnon website for use by
partner sites
Security questions can be
Not simulated – these features are standard
answered online or by calling a offerings of modern online services and the
supports number to unlock an RSA SecurID product
account; Temporary passwords
can be granted in the event of a
lost/damaged token
Customer support
Simulated by a Perl script running on a single
ODU server with a back-end DB populated with
the 20-50 valid token codes and related serial
numbers; Time-sensitive generation of
passcodes not simulated; One-time passcode
use will be simulated; Multiple bad attempts
causing account lockout will be simulated
Table 1. Feature comparison between full product and prototype
2.2 Prototype Functional Description
The major functional components are shown in Figure 2 above. A user will interact with
the CertAnon website and register a token using one of the serial numbers from the pre-defined
list. A PIN and several security questions will be selected during this process, which is shown
below in Figure 3. These actions will result in updates to the CertAnon accounts database.
12
Mirra 11/04/2007
Obtain list of
passcodes assigned
to a serialnumber
Visit CertAnon
website
Enter token serial
number and two
consecutive token
codes
Valid serial
number and
token codes?
Yes
Create CertAnon
username and PIN
No
No
3rd bad
attempt?
Set up security
questions/answers
Yes
CertAnon support
intervention
Log out of
CertAnon account
Figure 3. CertAnon prototype token setup process flow.
The user is able to associate a partner account with his or her token during the CertAnon
registration process or at any later date using the account maintenance interface. This
association process will result in an update to the CertAnon accounts database. Once the partner
site account has also been updated to indicate that CertAnon should be used for authentication,
the user can then attempt to log into the partner site using the CertAnon PIN and one token code.
Figure 4 illustrates the steps needed to configure an online account to use CertAnon.
13
Mirra 11/04/2007
Change password
for existing online
account
Use CertAnon for
authentication?
No
Set account
password
Color Scheme
Yes
Red - 3rd party account process
Blue - CertAnon process
Green - Interaction between them
Log into CertAnon
website with
CertAnon
username and
passcode (PIN +
token code)
Add online account
username and
domain to CertAnon
account
No
Does domain
support
CertAnon?
Yes
Confirm addition of
partner site account
Return to account
website
Authenticate with
CertAnon passcode
Figure 4. CertAnon prototype partner site account association process flow
When a user attempts to log into a Certanon-enabled partner site account, the
authentication module on the partner site will accept the entered information and transmit it to
the CertAnon mid-tier via a remote procedure call. The mid-tier will compare the domain name
and partner site username provided in the request with CertAnon user records in the accounts
database to determine the corresponding token. The mid-tier will then transmit the token serial
number and passcode to the authentication manager via another remote procedure call. The
authentication manager will compare the token code to the list of valid codes for the serial
number in the authentication manager database. A successful match will result in a database
update to set the "Used" flag of the token code. The authentication message will then be
returned as the result of the mid-tier's procedure call. The mid-tier will pass this back to the
14
Mirra 11/04/2007
authentication module of the partner site as the result of the module's procedure call. The
authentication module will present the user with an account home page if authentication was
successful. An authentication error message will be displayed if access was denied. Figure 5
shows the complete process flow for the authentication process.
Visit online account
website
Enter account
username and
CertAnon passcode
(PIN + token code)
Does account
use CertAnon
authentication?
No
Authenticate using
legacy password
mechanism
Yes
Color Scheme
Send authentication
request to
CertAnon servers
Red - 3rd party account process
Blue - CertAnon process
Green - Interaction between them
Recognize
requesting
server?
No
Refuse
authentication
request
No
Return invalid
username/domain
message
No
Return invalid
authentication
message
Yes
Valid username
and domain?
Yes
Valid
passcode?
Refuse account
access to user
Yes
Return successful
authentication
message
3rd bad
attempt?
Yes
Grant account
access to user
Return temporary
account lockout
message
Figure 5. CertAnon prototype partner site authentication process flow
15
No
Mirra 11/04/2007
The mid-tier will also update a "bad attempts" counter in the accounts database each time
the user is denied access. A successful login attempt will reset the "bad attempts" flag to zero.
Three consecutive bad attempts will cause the mid-tier to lock the CertAnon account by setting a
"Locked" flag in the accounts database, and future authentication requests will be blocked.
2.3 External Interfaces
External interfaces will be limited to standard PC hardware and freely available software.
The only custom interfaces will be the CertAnon and partner site websites.
2.3.1 Hardware Interfaces
No hardware interfaces will be built for this prototype. An ODU classroom PC will be
used to allow a test user to interface with the CertAnon and partner websites via the ODU
network. The websites and the CertAnon mid-tier and authentication manager processes will be
hosted on an ODU Sun Solaris server. These components will interact with each other locally as
well as across the ODU network. An ODU laptop will be used to monitor database contents and
process logs.
2.3.2 Software Interfaces
Group members will interface with the MySQL databases using standard, freely available
software such as MySQL Query Browser. PHP web pages will be developed using standard text
editing tools. The authentication manager will be written in Perl and will communicate with the
CertAnon mid-tier process via remote procedure calls.
16
Mirra 11/04/2007
2.3.3 User Interfaces
There will be three main user interfaces, all of which may be accessed by any Internetconnected PC with a web browser. The first interface is the CertAnon website. This site will
permit new users to register and allow existing users to maintain their CertAnon accounts. The
site map of the CertAnon website is shown in Figure 6.
CertAnon
Homepage
1.0
Register Now
Button
1.1
Help Page
1.3
Account Login
1.2
Initial Account
Setup
1.1.1
About CertAnon
1.4
Account
Maintenance
1.2.1
PIN Change
1.2.1.1
Security
Questions
1.2.1.2
Add/Modify/
Delete Linked
Accounts
1.2.1.3
Figure 6. Site map of the CertAnon website
The other two interfaces are the partner websites. These interfaces will provide a login
screen as well as a user-specific home page which is presented after a successful authentication.
They will also allow users to select CertAnon for authentication on an account preferences page.
The site map for the partner sites is shown in Figure 7.
17
Mirra 11/04/2007
Partner
Homepage
1.0
New Partner
Account
Register
1.1
Partner Account
Login
1.2
Partner Account
Homepage
1.2.1
Partner Account
Maintenance
1.2.1.2
Figure 7. Site map for the partner websites
2.3.4 Communication Protocols and Interfaces
Transmission Control Protocol/Internet Protocol (TCP/IP) over a standard Ethernet
connection will be the only communications protocol that is used.
3 Specific Requirements
The following section describes the specific functional, performance, and non-functional
requirements of the CertAnon prototype.
18
Mirra 11/04/2007
3.1 Functional Requirements
The functional requirements describe the capabilities of the CertAnon prototype. They
describe what the product must do in order to meet the previously discussed goals and objectives
of the project.
3.1.1 Initial Account Setup Interface
This function shall provide a mechanism for new users to register with the prototype
CertAnon service. The following functions shall be provided as part of a web interface:
1.
Accept and store a numeric token serial number of at least eight digits entered by a user
2.
Store a CertAnon username of at least eight alphanumeric characters in length and a PIN
of at least four alphanumeric characters chosen by a user
3.
Store security questions and answers input by a user for later use in emergency identity
verification
3.1.2 Account Maintenance Interface
This function shall provide a mechanism for registered users to make account changes.
The following functional capabilities shall be provided as part of a web interface:
1.
Allow a user to log in using a CertAnon username and passcode; A passcode shall consist
of a user's PIN concatenated with a six-digit numeric token code
2.
Allow a user to add, modify, and delete partner site domain names and corresponding
partner site usernames associated with the CertAnon account
3.
Allow a user to change and save the PIN associated with the CertAnon account
19
Mirra 11/04/2007
4.
Allow a user to change and save the security questions and answers associated with the
CertAnon account
3.1.3 User Authentication
The following requirements relate to the process of user authentication. The three main
pieces of this process are the authentication manager, the authentication module residing on
partner websites, and the mid-tier sitting between these two components.
3.1.3.1 Authentication Manager
This function provides for simulation of the RSA Authentication Manager software as the
primary method of user authentication. The following functional capabilities shall be provided:
1.
Accept a token serial number and passcode in the contents of an authentication request
2.
Compare a given passcode to the list of valid PIN/token code combinations for a given
serial number. The software should respond with an acceptance message if valid or a
rejection message otherwise.
3.
Operate persistently in the background so that it is always available to accept incoming
authentication requests
4.
Handle multiple simultaneous requests
5.
Enforce one-time usage of all token codes by throwing a rejection message for any
authentication request that contains a previously used token code
3.1.3.2 Authentication Module
This function will provide a mechanism through which a partner site can support
CertAnon authentication. The following functional capabilities shall be provided:
1.
Accept a username and password from the login page of a partner site
20
Mirra 11/04/2007
2.
Route authentication requests for non-CertAnon users to the internal legacy authentication
process
3.
Transmit a domain name, a partner site user name, and a passcode for a CertAnon user to
the CertAnon mid-tier process
4.
Accept return messages from the mid-tier and display appropriate messages to the user
5.
Handle authentication request time-outs due to an unresponsive mid-tier
3.1.3.3 Mid-Tier
This function will receive, translate, and forward communications between partner sites
and the authentication manger. The following functional capabilities shall be provided:
1.
Accept authentication requests sent by the authentication modules running on partner sites
2.
Compare the domain name and partner site username provided in a request with CertAnon
user records to determine the corresponding token
3.
Transmit token serial numbers and passcodes to the authentication manager process
4.
Accept return messages from the authentication manager process and forward them to the
requesting partner sites
5.
Record multiple failures and lock an account if three consecutive incorrect passcodes are
processed
6.
Handle authentication request time-outs due to an unresponsive authentication manager
3.1.4 Partner Sites
This function provides for simulation of websites that offer CertAnon authentication to
their customers. The following functional capabilities shall be provided:
1.
Provide data entry fields for username and password
21
Mirra 11/04/2007
2.
Allow a user to select or deselect an option to use CertAnon for authentication and save
this preference
3.
Accept and store a password entered by a user if CertAnon is not used for authentication
4.
Integrate the CertAnon authentication module
5.
Display a user-specific home page upon successful authentication
3.2 Performance Requirements
The following performance requirements describe how well the functions of the
CertAnon prototype shall be performed in quantifiable and measurable terms. These
requirements each correspond directly to one or more related functional requirements, and they
provide quantifiable and measurable goals for the service. The test cases currently under
development will be used to verify the attainment of these goals.
3.2.1 Authentication Manager
The authentication manager shall meet the following performance requirements:
1.
Respond to any authentication request within a maximum time of eight seconds
2.
Respond to authentication requests within an average time of three seconds
3.
Accept and process at least 20 concurrent authentication requests with no drops or denials
3.2.2 Authentication Module
The authentication module shall meet the following performance requirements:
1.
Handle up to 20 simultaneous authentication requests
3.2.3 Mid-Tier
The mid-tier shall meet the following performance requirements:
22
Mirra 11/04/2007
1.
Handle up to 20 simultaneous authentication requests
3.3 Assumptions and Constraints
Table 2 contains the full list of assumptions, constraints, and dependencies for the
prototype.
Condition
The speed of a user's Internet
connection can vary widely, and it is
outside of CertAnon's control
The domain name provided in an
authentication request is valid
A partner site username does not have
to be "real" or verifiable
SecurID tokens will be simulated by a
pre-defined list of token serial
numbers and associated token codes
An account cannot be associated with
multiple tokens
Only a specific pre-defined set of
token serial numbers can be registered
Type
Assumption
Effect on Requirements
Individual web page response times will not be tested
Assumption
Data transfer that would normally be
performed via an encrypted connection
will be done in plain text
Account unlock feature will not be
built
Constraint
Allows for minimal error checking for the purposes of developing
and demonstrating the prototype
Allows for minimal error checking and the use of preloaded
usernames on the simulated partner sites
The RSA SecurID is proven technology, and the time-sensitive
generation of token codes does not need to be simulated by a
hardware or software solution in the prototype
This bounds the problem of matching partner site user names with
token serial numbers for authentication
This restricts the universe of potential entries to a testable set. The
same constraint exists in the full product; tokens must be
registered with the authentication servers before they are available
for use
Simplifies the tasks of monitoring and demonstration
Valid token codes from the predefined list for a given token may be
accepted in any order
Constraint
Only the ODU server hosting the
partner sites will be submitting
authentication requests
An Internet connection is available at
the time of the demonstration
ODU servers will be available to host
the CertAnon components, and the
necessary software can be installed
Constraint
Assumption
Constraint
Constraint
Constraint
Constraint
Answering security questions by phone or on the web to unlock an
account is a standard feature of modern websites and is not an
innovative feature of CertAnon
This simplifies the problem of validating a user passcode entry.
Given the established operational record of the RSA SecurID
system, replicating this particular feature in the prototype is
unnecessary.
This bounds the problem of validating submitting servers and
reduces the need for error-checking
Dependency
The prototype cannot be demonstrated without one
Dependency
If this is not the case, personal hardware would need to be utilized
Table 2. Effects of Assumptions, Dependencies, and Constraints on Requirements
23
Mirra 11/04/2007
3.3.1 Assumptions
Three assumptions are being made. First, the speed of a user's Internet connection can
vary widely, and it is outside of CertAnon's control. Accordingly, individual web page response
times will not be tested. Second, the domain name provided in an authentication request is
assumed to be valid. Limiting the possible domain names reduces the amount of error checking
for the purposes of developing and demonstrating the prototype. Third, the partner site username
does not need to be real or verifiable. Accepting all entered usernames reduces the amount of
error checking that will be needed during data entry. Approximately 20 valid pre-loaded
usernames can be loaded on the simulated partner sites in advance of the prototype
demonstration for use in later authentication tests.
3.3.2 Constraints
A number of constraints will be used to limit the scope of the prototype, to simplify the
development process, and to focus on the innovative aspects of the service. There are four
constraints that have particular importance. First, SecurID tokens will be simulated by a predefined list of token serial numbers and associated token codes. The RSA SecurID is a proven
technology, and the time-sensitive generation of token codes does not need to be simulated by a
hardware or software solution in the prototype. Second, only a specific pre-defined set of token
serial numbers can be registered. The universe of potential entries is thereby limited to a testable
set. The same constraint exists in the full product because SecurID tokens must be registered
with the authentication servers before they are available for use. Third, data transfers that would
normally be performed via an encrypted connection will be done in plain text for monitoring and
demonstration purposes. Finally, valid token codes from the pre-defined list for a given token
24
Mirra 11/04/2007
may be accepted in any order. This simplifies the problem of validating a user passcode entry.
Given the established operational record of the RSA SecurID system, replicating this particular
feature in the prototype is unnecessary. The remaining constraints are included in Table 2.
3.3.3 Dependencies
There are two dependencies that have been identified for the CertAnon prototype.
Network and Internet connections must be available at the time of the demonstration. The
prototype cannot be demonstrated without these connections. In the event of a network outage,
a slide show will have to be utilized to explain the operation of the service. The other
dependency recognizes that ODU servers are expected to be available to host the CertAnon
components. Required software must also be installed. If this is not the case, personal hardware
would need to be utilized.
3.4 Non-Functional Requirements
Non-functional requirements address features of the prototype that are outside of the core
innovative functionality.
3.4.1 Security
An administration account must be created on the CertAnon and partner websites to
allow group members to manipulate data for all registered users through the web interfaces.
Group members will have privileges to update the back-end databases and website files and
code.
25
Mirra 11/04/2007
3.4.2 Maintainability
The pre-defined token serial numbers and associated token codes must be loaded on the
authentication server. Group members will be responsible for resetting the "Used" flag on all
token codes prior to each demonstration or test run. Account information on both the CertAnon
website and the partner websites must be deleted before the same user accounts can be recreated
during a test or demonstration.
3.4.3 Reliability
The CertAnon prototype must be available 24/7 to authenticate partner site users. The
service must complete 100% of its transactions with proper authentications or rejections. The
authentication manager, the authentication module, and the mid-tier are critical components that
must be available around the clock. The account registration and maintenance interfaces can be
non-functional for short periods of time. Making these interfaces unavailable could prevent new
users from registering or keep an existing user from modifying his accounts. This would not,
however, preclude an existing user from logging into linked partner sites.
4 Appendix
The appendix contains additional documentation for the CertAnon prototype.
4.1 Formal Resource Request Document
Team: Red Group
Project Manager: David Mirra
The following resources are required to be purchased for the prototype development and
demonstration of the CertAnon product:
26
Mirra 11/04/2007
Hardware Purchase (list all items required for purchase):
1. None
Software Purchase (list all items required for purchase):
1. None
The following University resources are required to support the prototype development and
demonstration:
1. Laptop/ Second computer
a. It will be used to display data flow and database content during the live
prototype demonstration.
b. Windows XP with connection to the internet
c. Quantity: 1
d. Date required: November 1, 2007
e. Deliver to: Red Group c/o Ben Blowe
2. MySQL installed on the ODU Computer Science server
a. This is the database we are using for our prototype.
b. Date required: October 12, 2007
3. PHP 5.x installed on the ODU Computer Science server
a. The websites used in the prototype will be written in PHP.
b. Date required: October 12, 2007
4. Perl 5.8.x installed on the ODU Computer Science server
a. Perl is needed for the simulation of the authentication manager software.
b. The following Perl modules should be installed:
1. Date::Manip
2. Getopt::Long
3. DBI
4. DBD::mysql
5. File::Flock
6. Net::Server::PreFork
7. SOAP::Lite
c. Date required: October 12, 2007
27