2 Way Mobile Authentication System is an innovative authentication solution that protects access to Web-based resources by providing a double-criterion user authentication through the use of existing mobile phones. It serves to overcome the security inadequacy of the Internet/Intranet, by allowing a user to authenticate him-self using his personal mobile phone. The user has to be registered using a secure method before he can use the system.
It is designed to protect Web-based Internet and Intranet applications, and requires users to identify themselves with two unique criterion - something they know (a username and password), and something they receive only during authentication (a one time password OTP delivered to their mobile phone) -- before they are granted access to a protected web resource. With 2WMAS, we can positively identify users and deliver valuable services conveniently and securely to users, without additional security hardware. End users can enjoy the benefits of a simple process that eliminates the need to remember multiple passwords or deal with cumbersome grid card.
As the Internet becomes a more important tool for financial transactions, the probability of an organization's transaction system security being compromised increases. Transactions today are secured using passwords. Institutions spend millions of dollars on secure SSL solutions to ensure passwords are not captured. But, in most cases, as we shall see in the next few real world cases, security breach occurs outside the reach of PKI and SSL solutions.
How the traditional password system can be compromised
Passwords can be captured while they are being entered into the browser. For instance, by 'trogan- horse' applications which most of users might have unknowingly installed, while installing shareware applications, while reading a malicious email, or while even visiting a dubious website. Some 'trojan-horse' applications like the infamous 'Back Orifice' can even control PCs, and allow hackers to view their screens the same way as a remote software application like PCanywhere!
Some users may store their passwords carelessly on their PCs, which can be seen by anyone with access to the terminals, including their PC repairman, or if they are using a cybercafe machine, anyone who uses that terminal after them.
An inefficient programming APIs of a system might give clues to the hackers to by pass the entire system.
Core features of 2 Way Mobile Authentication System
Double-criterion to identify the User:
It provides a cost-effective way to protect web resources with a double-criterion authentication. Through a browser, a user requests access to a Web resource which requires additional authentication requested by the Web Application. It then generates a unique, one-time access code and sends it to the user's mobile phone, either as an SMS text message or as an e-mail. The user enters the access code into the browser to complete the authentication process. When a user submits authentication information, the system determines whether the information is valid and provides the final go-ahead to the Web Application. By separating Web Application with Authentication server, we can also segregate responsibility to reduce the likelihood of internal fraud.
Protecting existing authentication system:
It does not replace existing authentication system, but rather serves as an additional layer of security that protects and complements existing authentication system, whether software or hardware based.
Protecting against Internal fraud:
The entire system's core authentication and messaging engine is such that it provides a greater level of protection against the risk of de-compilation and reverse engineering. A security platform can never be secured if anyone with access to parts of the application can view its security algorithm, modify code to reveal weaknesses or even create a backdoor.
Limitations on 2 Way Mobile Authentication System
It cannot overcome phishing (phishing is the criminally fraudulent process of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication)
Users have natural problems retaining a single authentication factor like a password. It is not uncommon for users to be expected to remember dozens of unique passwords. In this system, where one factor is a password, does not eliminate this problem. One possible solution is to have the second factor be a biometric or a virtual token number that the user does not need to remember, instead of an entity that the user needs to memorize.
A user cannot login to the system if the GSM gateway service providers' servers are down where he could not receive the OTP even though he is a genuine user.
Market Segments where 2WMAS is in use
Enterprise
a. Secure remote access
b. Enterprise authentication
c. B2B Transactions
Consumer
a. Online banking
b. e-commerce
c. Internet Service Providers
Government
a. Common authentication
b. Biometrics
TECHNOLOGIES
Software Requirements
Application Language : HTML / CSS / Java Script and PHP
Operating System : Linux / Windows
Protocols : HTTP
Web Server : Apache
FIPS 180 -1 Standard:
The Federal Information Processing Standards Publication Series
Of the National Institute of Standards and Technology (NIST) is the
Official series of publications relating to standards and guidelines
Adopted and promulgated under the provisions of Section 111(d) of the
Federal Property and Administrative Services Act of 1949 as amended by
The Computer Security Act of 1987, Public Law 100-235. These mandates
Have given the Secretary of Commerce and NIST important responsibilities
For improving the utilization and management of computer and related
elecommunications systems in the Federal Government. The NIST, through
the Computer Systems Laboratory, provides leadership, technical guidance,
and coordination of Government efforts in the development of standards
and guidelines in these areas.
This standard specifies a Secure Hash Algorithm (SHA-1) which can
be used to generate a condensed representation of a message called a
message digest. The SHA-1 is required for use with the Digital Signature
Algorithm (DSA) as specified in the Digital Signature Standard (DSS) and
whenever a secure hash algorithm is required for Federal applications.
The SHA-1 is used by both the transmitter and intended receiver of a
message in computing and verifying a digital signature.
SHA - 1 Algorithm :
SHA-1 is used to compute a message digest for a message or data file that is provided as input. The message or data file should be considered to be a bit string. The length of the message is the number of bits in the message (the empty message has length 0). If the number of bits in a message is a multiple of 8, for compactness we can represent the message in hex. The purpose of message padding is to make the total length of a padded message a multiple of 512. SHA-1 sequentially processes blocks of 512 bits when computing the message digest. The following specifies how this padding shall be performed.
As a summary, a "1" followed by m "0"s followed by a 64- bit integer are appended to the end of the message to produce a padded message of length 512 * n. The 64-bit integer is the length of the original message. The padded message is then processed by the SHA-1 as n 512-bit blocks.
Suppose a message has length l < 2^64. Before it is input to the SHA-1, the message is padded on the right as follows:
"1" is appended. Example: if the original message is "01010000", this is padded to "010100001".
"0"s are appended. The number of "0"s will depend on the original length of the message. The last 64 bits of the last 512-bit block are reserved, for the length l of the original message.
Example: Suppose the original message is the bit string
01100001 01100010 01100011 01100100 01100101.
After step (a) this gives
01100001 01100010 01100011 01100100 01100101 1.
Since l = 40, the number of bits in the above is 41 and 407 "0"s are appended, making the total now 448.
This gives (in hex)
61626364 65800000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000.
Obtain the 2-word representation of l, the number of bits in the original message. If l < 2^32 then the first word is all zeroes. Append these two words to the padded message.
Example: Suppose the original message is as in (b). Then l = 40 (note that l is computed before any padding). The two-word representation of 40 is hex 00000000 00000028. Hence the final padded message is hex
61626364 65800000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000028.
The padded message will contain 16 * n words for some n > 0. The padded message is regarded as a sequence of n blocks M(1) ,M(2), first characters (or bits) of the message.
A sequence of logical functions f(0), f(1),..., f(79) is used in SHA-1. Each f(t), 0 <= t <= 79, operates on three 32-bit words B, C, D and produces a 32-bit word as output. f(t;B,C,D) is defined as
follows: for words B, C, D,
f(t;B,C,D) = (B AND C) OR ((NOT B) AND D) ( 0 <= t <= 19)
f(t;B,C,D) = B XOR C XOR D (20 <= t <= 39)
f(t;B,C,D) = (B AND C) OR (B AND D) OR (C AND D) (40 <= t <= 59)
f(t;B,C,D) = B XOR C XOR D (60 <= t <= 79).
A sequence of constant words K(0), K(1), ... , K(79) is used in the
SHA-1. In hex these are given by
K(t) = 5A827999 ( 0 <= t <= 19)
K(t) = 6ED9EBA1 (20 <= t <= 39)
K(t) = 8F1BBCDC (40 <= t <= 59)
K(t) = CA62C1D6 (60 <= t <= 79).
The below methods yield the same message digest. Although using method 2 saves sixty-four 32-bit words of storage, it is likely to lengthen execution time due to the increased complexity of the address computations for the { W[t] } in step (c). There are other computation methods which give identical results.
The message digest is computed using the message padding as discussed above. The computation is described using two buffers, each consisting of five 32-bit words, and a sequence of eighty 32-bit words. The words of the first 5-word buffer are labeled A,B,C,D,E. The words of the second 5-word buffer are labeled H0, H1, H2, H3, H4. The words of the 80-word sequence are labeled W(0), W(1),..., W(79). A single word buffer TEMP is also employed.
To generate the message digest, the 16-word blocks M(1), M(2),..., M(n) defined in section 4 are processed in order. The processing of each M(i) involves 80 steps.
Before processing any blocks, the H's are initialized as follows: in hex,
H0 = 67452301
H1 = EFCDAB89
H2 = 98BADCFE
H3 = 10325476
H4 = C3D2E1F0.
Now M(1), M(2), ... , M(n) are processed. To process M(i), we proceed as follows:
a. Divide M(i) into 16 words W(0), W(1), ... , W(15), where W(0) is the left-
most word.
b. For t = 16 to 79
let W(t) = S^1(W(t-3) XOR W(t-8) XOR W(t-14) XOR W(t-16)).
c. Let A = H0, B = H1, C = H2, D = H3, E = H4.
d. For t = 0 to 79 do
TEMP = S^5(A) + f(t;B,C,D) + E + W(t) + K(t);
E = D; D = C; C = S^30(B); B = A; A = TEMP;
e. Let H0 = H0 + A, H1 = H1 + B, H2 = H2 + C, H3 = H3 + D, H4 = H4+E
After processing M(n), the message digest is the 160-bit string represented by the 5 words H0 H1 H2 H3 H4.
The method above assumes that the sequence W(0), ... , W(79) is implemented as an array of eighty 32-bit words. This is efficient from the standpoint of minimization of execution time, since the addresses of W(t-3), ... ,W(t-16) in step (b) are easily computed. If space is at a premium, an alternative is to regard { W(t) } as a circular queue, which may be implemented using an array of sixteen 32-bit words W[0], ... W[15]. In this case, in hex let MASK = 0000000F. Then processing of M(i) is as follows:
a. Divide M(i) into 16 words W[0], ... , W[15], where W[0] is the
left-most word.
b. Let A = H0, B = H1, C = H2, D = H3, E = H4.
c. For t = 0 to 79 do
s = t AND MASK;
if (t >= 16) W[s] = S^1(W[(s + 13) AND MASK] XOR W[(s + 8) ANDMASK] XOR W[(s + 2) AND MASK] XOR W[s]);
TEMP = S^5(A) + f(t;B,C,D) + E + W[s] + K(t);
E = D; D = C; C = S^30(B); B = A; A = TEMP;
d. Let H0 = H0 + A, H1 = H1 + B, H2 = H2 + C, H3 = H3 + D, H4 = H4+E
Server- Side Scripting Language - PHP:
PHP: Hypertext PRE Processor, is a widely used, general-purpose and server side scripting language that was originally designed for web development, to produce dynamic web pages. It can be embedded into HTML and generally runs on a web server, which needs to be configured to process PHP code and create web page content from it. It can be deployed on most web servers and on almost every operating system and platform free of charge. PHP is installed on over 20 million websites and 1 million web servers.
Features of PHP (Server-Side Scripting Language) :
Standard CGI, Fast-CGI and Apache module support - As a standard CGI program, PHP can be installed on any UNIX machine running any UNIX web server. With support for the new Fast-CGI standard, PHP can take advantage of the speed improvements gained through this mechanism. As an Apache module, PHP becomes an extremely powerful and lightning fast alternative to CGI programming.
Access Logging - With the access logging capabilities of PHP, users can maintain their own hit counting and logging. It does not use the system's central access log files in any way, and it provides real-time access monitoring. The Log Viewer Script provides a quick summary of the accesses to a set of pages owned by an individual user. In addition to that, the package can be configured to generate a footer on every page which shows access information. See the bottom of this page for an example of this.
Access Control - A built-in web-based configuration screen handles access control configuration. It is possible to create rules for all or some web pages owned by a certain person which place various restrictions on who can view these pages and how they will be viewed. Pages can be password protected, completely restricted, logging disabled and more based on the client's domain, browser, e-mail address or even the referring document.
RFC-1867 File Upload Support - File Upload is a new feature in Netscape 2.0. It lets users upload files to a web server. PHP provides the actual Mime decoding to make this work and also provides the additional framework to do something useful with the uploaded file once it has been received.
HTTP-based authentication control - PHP can be used to create customized HTTP-based authentication mechanisms for the Apache web server.
Variables, Arrays, Associative Arrays - PHP supports typed variables, arrays and even Perl-like associative arrays. These can all be passed from one web page to another using either GET or POST method forms.
Conditionals, While Loops - PHP supports a full-featured C-like scripting language. You can have if/then/elseif/else/endif conditions as well as while loops and switch/case statements to guide the logical flow of how the html page should be displayed.
Extended Regular Expressions - Regular expressions are heavily used for pattern matching, pattern substitutions and general string manipulation. PHP supports all common regular expression operations.
Raw HTTP Header Control - The ability to have web pages send customized raw HTTP headers based on some condition is essential for high-level web site design. A frequent use is to send a Location: URL header to redirect the calling client to some other URL. It can also be used to turn off cacheing or manipulate the last update header of pages.
ISP "Safe Mode" support - PHP supports an unique "Safe Mode" which makes it safe to have multiple users run PHP scripts on the same server.
Many more new features are being added in newer releases of PHP. Visit the main web site at http://www.php.net
It's Free! - One final essential feature. The package is completely free. It is licensed under the GNU/GPL which allows you to use the software for any purpose, commercial or otherwise.
Client Side Scripting Languages (HTML / CSS / Javascript) :
Client-side scripting generally refers to the class of computer programs on the web that are executed client-side, by the user's web browser, instead of server-side (on the web server).This type of computer programming is an important part of the Dynamic HTML (DHTML) concept, enabling web pages to be scripted; that is, to have different and changing content depending on user input, environmental conditions (such as the time of day), or other variables. Client-side scripts are often embedded within an HTML document, but they may also be contained in a separate file, which is referenced by the document that use it. Upon request, the necessary files are sent to the user's computer by the web server on which they reside. The user's web browser executes the script, and then displays the document, including any visible output from the script. Client-side scripts may also contain instructions for the browser to follow if the user interacts with the document in a certain way, e.g., clicks a certain button. These instructions can be followed without further communication with the server.
Database - MYSQL:
MYSQL is a relational database management system (RDBMS) that has more than 6 million installations. MYSQL stands for "My Structured Query Language". The program runs as a server providing multi-user access to a number of databases. On top of that, it is very commonly used in conjunction with PHP scripts to create powerful and dynamic server-side applications. Many more new features are being added in newer releases of MYSQL. The main web site is at http://www.mysql.com
SMS Gateway Service Provider (www.clickatell.com) :
Clickatell provides an interface between our existing systems and the Messaging Gateway. It is a lower level connectivity option, but offers the most functionality and flexibility for the end user. With the API we can set up alert-based SMS delivery from our server. Depending on our messaging requirements, we may find one or more of Clickatell's products to suit our needs, out of which we have opted HTTP API which is one of the simpler ways to connect to the Clickatell API to send SMS.
HTTP/HTTPS API is one of the simpler server-based forms of communication to Clickatell's gateway. It can be used either in the form of a HTTP POST, or as a URL (GET). It is recommended to POST for larger data transfer, due to the size limitations of GET. Communication to the API can be done either via HTTP on port 80 or HTTPS on port 443. All calls to the API must be URL-encoded. The parameter names are case-sensitive. Batch messaging is catered for in a variety of ways. To use this API, we need to register at: www.clickatell.com and create an account to buy the SMS credits to send SMS.
Below is the procedure to send an SMS using clickatell (mentioned below is manual, we need to program it accordingly to integrate)
First we need to sign up for an HTTP/S account; we will be given a username, password and api_id.
Once the registration has been activated we will receive 10 free credits with which to test our service.
Have the number we wish to send to ready in international format e.g. 448311234567.
Open the browser (e.g. Internet Explorer), and type in the info in the address bar in the following sequence: http://api.clickatell.com/http/sendmsg?user=xxxxx&password=xxxxx&api_id=xxxxx&to=448311234567&text=Meet+me+at+home
The text of the message must be formatted so that '+' signs replace spaces between words as above.
Press 'Enter' on the keyboard and the message will be sent.
Programming Process:
Below are the steps to be followed to demonstrate two way mobile authentication systems:
Create a project flow design.
Design good looking and attracting web pages and site flow with Hypertext markup language (HTML) and Cascading Style sheets (CSS).
Decide the database structure to store the registered users contact , log-in and account details.
Develop the code needful to navigate the application dynamically.
Integrate the Clickatell's HTTP/HTTPS API to our system to send SMS (which include the one-time password (OTP) generated by the SHA-1 algorithm)
Test the application to locate and remove any bugs.
Compile the tested application and deploy the files in the server.
Buy a domain name and point it to our server to make it live.
Programming Maintenance:
Apart from the bugs, we have to maintain the program we created. Program Maintenance is a term used for the updating of a program after the program is put into use. This updating may be a result of the users request or a change in the way the program needs to operate.
SYSTEM DESIGN
Data Flow Diagram
UML Diagram
The Unified Modeling Language allows the software engineer to express an analysis model using the modeling notation that is governed by a set of syntactic semantic and pragmatic rules.
Use case Diagrams represent the functionality of the system from a user's point of view. Use cases are used during requirements elicitation and analysis to represent the functionality of the system. Use cases focus on the behavior of the system from external point of view.
Actors are external entities that interact with the system. Examples of actors include users like administrator, bank customer …etc., or another system like central database.
Use Case
DATABASE DESIGN
Database : bthbanken
Username : bthbanken
Password : Qua4rigadb
TABLE STRUCTURE
CREATE TABLE `user_balance` (
`user_id` int(10) NOT NULL default '0',
`acc_balance` varchar(255) NOT NULL default '0',
PRIMARY KEY (`user_id`)
);
CREATE TABLE `user_details` (
`user_id` int(10) NOT NULL default '0',
`firstname` varchar(255) NOT NULL default '',
`lastname` varchar(255) NOT NULL default '',
`email` varchar(255) NOT NULL default '',
`address` varchar(255) NOT NULL default '',
`contactnumber` varchar(255) NOT NULL default '',
`alternatenumber` varchar(255) NOT NULL default '',
`state` varchar(255) NOT NULL default '',
`zip` int(20) NOT NULL default '0'
);
CREATE TABLE `user_login` (
`user_id` int(10) NOT NULL auto_increment,
`user_name` varchar(255) NOT NULL default '',
`user_pass` varchar(255) NOT NULL default '',
PRIMARY KEY (`user_id`),
UNIQUE KEY `user_name` (`user_name`)
);
CREATE TABLE `user_received` (
`user_id` int(10) NOT NULL default '0',
`received_bank_name` varchar(255) NOT NULL default '',
`received_acc_number` varchar(255) NOT NULL default '0',
`amount_received` varchar(255) NOT NULL default '0',
`transaction_date` varchar(255) NOT NULL default ''
);
CREATE TABLE `user_transfer` (
`user_id` int(10) NOT NULL default '0',
`destination_bank_name` varchar(255) NOT NULL default '',
`destination_acc_number` varchar(255) NOT NULL default '0',
`amount_transferred` varchar(255) NOT NULL default '0',
`transaction_date` varchar(255) NOT NULL default ''
);
user_login
Attributes : user_id, user_name, user_pass
user_id : It is an auto incremented field which track the number of users registered with the bank. It is the primary key for this table.
user_name : It stores the username of a registered user which is unique.
user_pass : It stores the password corresponding to a username.
user_details
Attributes : user_id, firstname, lastname, email, address, contactnumber, alternatenumber, state, zip
user_id : It is a field which corresponds to the user_id in user_login table.
firstname : It stores the First name of the registered user.
lastname : stores the Last name of the registered user.
email : stores the email id of the registered user.
address : stores the address
contactnumber : stores the mobile number of the user to which the SMS has to be sent.
alternatenumber : this field is optional and stores the alternate number of the user.
state : stores the resident state.
zip : stores the zipcode of the resident.
user_balance
Attributes : user_id, acc_balance
user_id : It is a field which corresponds to the user_id in user_login table.
acc_balance : It stores the net balance of a account holder. By default its value is zero.
user_received
Attributes : user_id, received_bank_name, received_acc_number, amount_received, transaction_date
user_id : It is a field which corresponds to the user_id in user_login table.
received_bank_name : It stores the name of the bank from which a user receives money.
received_acc_number :It stores the account number of the user who transfers the money.
amount_received : It stores the amount received.
transaction_date : stores the date of the transaction.
user_transfer
Attributes : user_id, destination_bank_name, destination_acc_number, amount_transferred, transaction_date
user_id: It is a field which corresponds to the user_id in user_login table.
destination_bank_name: It stores the name of the bank to which the money has to be transferred.
destination_acc_number:It stores the account number of the user to transfer the money.
amount_transferred: It stores the amount transferred.
transaction_date : stores the date of the transaction.
IMPLEMENTATION
index.php
This is the home page of the site and include links to login, new user sign up and forgot password.
register.php
This is the registration page of a new user to the bank, where the user enters his login and contact details. This program performs basic client side (Javascript) validations of the details entered. On submitting this page will redirect to loginform.php
loginform.php
This page checks whether the username submitted in register.php already exists in the database, if exists then, it will again redirect to register.php throwing an error "username already exist, please try another one..." and if does not exist, It will perform the following steps:
inserts a new user login details in user_login table namely, username and password. The user_id is an auto incremented field and increments its value by 1.
based on the last inserted user_id in user_login table, it will insert a new record in user_details table updating all the contact details of the user.
inserts a new record in user_balance table by a default value of zero in acc_balance (account balance)
Displays the login form and on submitting this form will redirect to login_home.php
login_home.php
It checks the whether the posted login details are valid or not. If they are invalid then, it redirects to index.php throwing an error message "invalid username / password"
Else if valid then, it performs the following steps:
connects to the database and fetch the user_id of the username and password submitted and stores in a session variable.
creates a one time password (OTP) based on the SHA1 algorithm and stores it in a session variable.
retrieves the contact number of the user, based on the user_id from the table user_details.
creates a query string to send an SMS based on clickatells API procedure and sends an sms to the contact number retrieved.
after sending the sms it will redirect the page to authenticate_password.php
authenticate_password.php
This page asks the user to enter the OTP sent to his mobile via SMS and on submitting this page will redirect to verify_password.php
verify_password.php
This page checks whether the entered OTP is equal to the already stored session password variable and if it is correct will redirect the page to transaction.php else it will again redirect the page to authenticate_password.php throwing an error "you have entered wrong password, please try again..."
transaction.php
This page performs the following:
Displays the account id which is same as user_id.
Retrieves the account balance of the user from user_balance and displays it.
Displays the credited and debited details from the table user_transfer and user_received accordingly.
add_money.php
This page displays a form asking the user an amount to add to his account balance. On submitting this page will post the values to verify_add.php
verify_add.php
It will update the acc_balance field in the user_balance by adding the existing and the posted amount and redirect to transaction.php
bank_selection.php
It shows two options for the money transfer namely, "same bank" or "other bank". On selection of the options will submit the page to redirect.php
redirect.php
It will redirect the page to samebank.php or otherbank.php based on the selection of money transfer in bank_selection.php
samebank.php
It shows the existing account numbers - names of the bank and asks for the amount to be transferred. On submitting this form will redirect the page to same_auth.php
same_auth.php
This page performs the following:
Stores the amount and account number posted from the samebank.php in a session variable.
Creates a one time password (OTP) based on the SHA1 algorithm and stores it in a session variable.
Retrieves the contact number of the user, based on the user_id from the table user_details.
Creates a query string to send an SMS based on clickatells API procedure and sends an sms to the contact number retrieved.
asks the user to enter the OTP sent to his mobile via SMS and on submitting this page will redirect to aftersame_auth.php
aftersame_auth.php
This page checks whether the entered OTP is equal to the already stored session password variable and if it is not correct, will redirect the page to same_auth.php throwing an error "you have entered wrong password, please try again..." else if correct, it performs the following:
Deducts the transferred amount from the existing balance in user_balance.
Adds the same amount to the transferred account number.
Inserts a new record in user_transfer updating the details of the transferred bank, account number and the transaction date. (credited details)
Adds the transferred amount to the account number (i.e user_id) to which the money is transferred.
Inserts a new record in user_received updating the details of the transferred bank, account number and the transaction date. (debited details)
Redirects the page to success.html showing a message "your transaction is successfully completed".
otherbank.php
It asks the user to enter the account number, bank name and the amount to be transferred. On submitting this form will redirect the page to other_auth.php
other_auth.php
This page performs the following:
Stores the amount ,account number and the bank name posted from the otherbank.php in a session variable.
Creates a one time password (OTP) based on the SHA1 algorithm and stores it in a session variable.
Retrieves the contact number of the user, based on the user_id from the table user_details.
Creates a query string to send an SMS based on clickatells API procedure and sends an sms to the contact number retrieved.
asks the user to enter the OTP sent to his mobile via SMS and on submitting this page will redirect to afterother_auth.php
afterother_auth.php
This page checks whether the entered OTP is equal to the already stored session password variable and if it is not correct, will redirect the page to same_auth.php throwing an error "you have entered wrong password, please try again..." else if correct, it performs the following:
Deducts the transferred amount from the existing balance in user_balance.
Inserts a new record in user_transfer updating the details of the transferred bank, account number and the transaction date. (credited details)
Redirects the page to success.html showing a message "your transaction is successfully completed".
Sample Coding
/* code to generate OTP and storing it in a session variable for comparison in the next step */
$otp = sha1(mt_rand());
$otp_password = substr($otp, 0, 6);
$_SESSION['OTP'] = $otp_password;
/* below is the code to send a request to clickatell's API to send an SMS */
$clickatell_sms_url = "http://api.clickatell.com/http/sendmsg?";
$clickatell_username = "rajan_eeitc";
$clickatell_password = "Cefuv123";
$clickatell_api_id = "3205489";
$clickatell_to = "46".$sms_mobile_number['contactnumber'];
$clickatell_message = "BTH+BANKEN+Authentication+Password+:+".$otp_password."++Thank+you+for+registering+an+account+with+BTH+BANKEN";
$clickatell_query_string = $clickatell_sms_url."user=".$clickatell_username."&password=".$clickatell_password."&api_id=".$clickatell_api_id."&to=".$clickatell_to."&text=".$clickatell_message;
$send_sms = file_get_contents($clickatell_query_string);
TESTING
Testing Objectives
In light of the diversity of existing software testing, it is advantageous to consider the types of tests as they become available to a designer. This will also help identify the scope of a particular test and clarify its main advantages and disadvantages as well as make the developer aware about the limitations of this test.
Functional Tests are used to exercise the code with nominal inputs (input values) for which the expected values are available. We also know the boundary conditions for these inputs. For instance, functional testing of matrix multiplication can involve some data (matrices) for which the results are known in advance.
Performance Tests are utilized in order to determine the widely defined performance of the software system such as an execution time associated with various parts of the code, response time(in case of embedded systems),and device utilization. The intent of this type of testing is to identify weak points of a software system and quantifying its shortcomings, leading to further improvements.
Stress Tests are designed to break a software module. This type of testing determines the strengths and limitations of the software. Structure Tests are aimed at exercising the internal logic of a software system.
Testing In Small-Testing In the Large: The underlying criterion concerns which part of the system is subject to testing. If we are concerned with the individual modules, procedures and functions then, this lead to testing in the small. Testing in the large is primarily devoted to integration testing when the system is developed out of some already constructed modules.
Black Box-White (Glass) Box Testing: As the name suggests, the criterion leading to this type of discrimination specifies whether the internal (logical) structure of the system is available for testing purposes. If so, we are concerned with white box testing. If the internal structure is not available or exercised when developing the test suite, we confine ourselves to black box testing. Depending which way was selected, the points of view on testing are also radically different. In black box testing we are interested to test what the system is supposed to do. The testing is worked out from input data perspective; subsequently we see if the outputs (actions) of the software match the expected values. Functional, stress, and performance tests fall under this general category. In white box testing, testing concentrates on what the system does. Essentially, using detailed knowledge of code, one creates a battery of tests in such a way that they exercise all components of the code (say, statements, branches, paths).structural testing sub schemes white box testing.
Test Activities
In software testing we encounter a number of key activities:
Test plans
Test design
Test Cases
Test procedure
Test execution
Test report
A test plan indicates the scope, approach, resources and the schedule of testing activity. At this stage, one indicates what is to be or not to be tested and which tasks to perform. In addition, it is necessary to identify the sources and levels of risk in testing. Software testers are also identified. Test planning may begin as soon as the requirements are completed.
The key features in a test plan are
Transitioning
Estimates
Completion
Risk analysis allocation
It is difficult to determine when to stop testing or when a reasonable number of faults have been detected. For these reasons, criteria should be provided as a guideline for test completion. A test design refines the approach in a test plan. Test design also identifies specific features to be tested by the design, and define the associated test cases. It is strongly suggested that tests should be designed for regression testing (test previously executed can be repeated at a later point in development and maintenance).the test cases and test procedures are constructed in an implementation phase. One should strive for the most compact (smallest) collection of test cases (batteries) that still meet the goal. Good test cases have a high probability of detecting undiscovered errors. A test procedure identifies all steps required to operate the system and exercise the specified test cases to implement the already defined test design. Test execution is the exercising of the test procedures. Test execution starts from the component level and moves up to the integration, system and acceptance level. a test report summarizes all outcomes of testing and highlights the discrepancies detected. Sting activities are distributed across the entire software life-cycle as shown in the figure
Requirements
Design
Implementation
Test
Test plan
generation
Test design
Generation
Test case
Generation
Test procedure
Generation
Test execution
Phases of Testing
Testing can be divided into a number of phases as shown below:
Program Testing
System Testing
User Acceptance Testing
Program Testing:
The purpose of program testing is to check out whether the program is working accordingly to the specification given. This phase ensures that the program or modules as expected. In this phase, all parts of the program are checked thoroughly
System Testing:
System testing should prove that the computer system work as intended and are acceptable to user operations and audit. It would also show that the system would interface correctly with other existing computer systems. The running of system test should be under the control of operations, it can also prove that all the operations, so that operating procedures can prove to be correct. There should be sufficient volume of data to demonstrate that the system meets the performance constraints.
User Acceptance Testing:
User acceptance testing to be performed must be established and agreed during analysis. It may be urn in parallel with the existing system so that users will create special test data. The key difference between system testing and user acceptance testing is that the user is interested in the inputs and outputs. The inputs and outputs are verified with existing system and checked to see if it is the same.
Level of Testing
There are two levels of testing used the package they are:
Unit Testing
System Testing
Unit Testing:
Unit testing focuses verification effort on the smallest unit of software design. Unit testing is simplified when a module with high cohesion is designed. In unit testing various programs, which comprises the system are tested separately. So unit testing is sometimes called as "Program Testing". This reduces the error produced by the larger program.
System Testing:
It is used to find the integration of each module in the system. It is also tested to find discrepancies between the system and its original objectives, current specification and system documentation. System testing is a series of different test whose primary purpose is to fully exercise the computer-based system. Testing is used to find the compatibility between the various programs units available in the system.
Testing Strategies
Testing of software's is done in the aim of finding errors. Test cases are devised to bring out errors in the system. The test data are created with the intention of determining whether the system will program will handle them appropriately. There are two general testing strategies for testing software namely:
Code Testing
Specification Testing
Validation Testing
Code Testing:
The code testing strategy examines the logic of the program. Test cases are devised such that they result in executing every instruction in the program (i.e.) every path of the program is tested. Specification testing handles all these problems.
Specification Testing:
Specification Testing involve stating what the program should and how it should perform under various conditions. The test are developed for each condition or combination of condition and submitted for processing. By examining the results we can determine where the program performs according to its specified requirements.
Validation Testing:
Validation can be defined in many ways, but a simple definition is that validation succeeds when software functions in a manner that can be reasonable expected by the customer. Software validation is achieved through a series of black box tests that demonstrate conformity with requirements.
SCREEN SHOTS
