SRS Graphical Password Authentication system

14  Download (0)

Full text

(1)

Graphical Password Authentication

System

Software Requirement Specification

Version 1.0

Prepared by

Group No.2

Adhwaith K. A 12019422

Nevin Francis 12019504

Sanju Samuel 12019521

S6 B.Tech

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

VISWAJYOTHI COLLEGE OF ENGINEERING & TECHNOLOGY,

VAZHAKULAM

MAHATMA GANDHI UNIVERSITY, KOTTAYAM

(2)

Table of Contents

Table of Contents...ii

Revision History...iii

1. Introduction...1

1.1 Purpose...1 1.2 Document Conventions...1

1.3 Intended Audience and Reading Suggestions...1

1.4 Product Scope...2

1.5 References...2

2. Overall Description...2

2.1 Product Perspective...2

2.2 Product Functions...2

2.3 User Classes and Characteristics...3

2.4 Operating Environment...3

2.5 Design and Implementation Constraints...4

2.6 User Documentation...4

2.7 Assumptions and Dependencies...4

3. External Interface Requirements...4

3.1 User Interfaces...4

4. System Features...4

4.1 Graphical Password Generation………...6

4.2 User Login...6

4.3 Uploading file with integrated security...6

4.4 Downloading file………...7

5. Other Nonfunctional Requirements...7

5.1 Performance Requirements...7

5.2 Safety Requirements...7

5.3 Security Requirements...7

5.4 Software Quality Attributes...7

5.5 Business Rules...8

6. Other Requirements...8

Appendix A: Glossary...8

(3)

Revision History

Name Date Reason For Changes Version

Nevin Francis 05-3-2015 Initial stage 1.0

Adhwaith K.A 05-3-2015 Initial stage 1.0

(4)

1. Introduction

1.1 Purpose

This software requirement specification (SRS) document describes the functional and non-functional description of the “Graphical Password Authentication System “ release version 1.0. The working and objectives is briefly summarized followed by detailed description of the system’s scope, vision, use case, features and other related requirement issues. In the project’s later phases, such as system design, database design, implementation and testing, this document should be referred as functional model of the system for release 1.0.

1.2 Document Conventions

All system development activities should follow the final version of this document. Any discrepancy that found during in later phases should be modified subject to SRS. However, this document may be subjected to change depending on the decision of the group members.

The typographical conventions used in writing this SRS are:

 SRS main headings: Font=Times New Roman, Bold, Size=18.

 SRS headings: Font=Times New Roman, Bold, Size=18.

 SRS sub headings: Font=Times New Roman, Bold, and Size=14.

 SRS Body text: Font=Times New Roman, Size=11.

 Header & Footer – Font Size: 10, Bold & Italics, Times New Roman. The document contains header on all pages. The header is the name of the project on top left end and page number on the top right end of the page.

 Bullets are used to denote main points in the section.

1.3 Intended Audience and Reading Suggestions

The document is intended for different types of readers such as developers, administrator and the authorized users. The rest of this SRS contains an overall description, external interface requirements, system features and other non-functional requirements.

Developers and testers can go through the details mentioned from topic 2 to 5. Tester can rely on the document section 4, where each system feature is listed. Database designers will be interested on sections 2.5 and 3.

(5)

1.4 Product Scope

The main aim of this project, ‘Graphical Authentication System’ is to send an image secretly. The system focus is to keep the secrecy of the image. The project has immense scope in the fields of astronomy, industrial implementation, institutional implementation, and scientific fields. In the present context, the project has wide scope to keep the images privately.

1.5 References

[1] [IEEE Standard 181-1998]: The standard followed by the current SRS.

[2] Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, 7th Edition, McGraw-Hill, Singapore, 2011.

[3] Bin B. Zhu, Jeff Yan, Guanbo Bao, Maowei Yang, and Ning Xu,”Captcha as Graphical Passwords—A New Security Primitive Based on Hard AI Problems”, IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 9, NO. 6, JUNE 2014

2. Overall Description

2.1 Product Perspective

In this project, main aim is to enhance security of user login using GRAPHICAL passwords. Enhanced security measures will be taken to improve the security of the files uploaded using the same technology.

2.2 Product Functions

In this project, we are using functions such as:

 Graphical password generation

 Authentication

(6)

Level 0 DFD:

2.3 User Classes and Characteristics

Generally the users are classified into two:

 Administrator

 Users

Admin is responsible for the maintenance of the software and he will see for the security measures

for the system. He should be given the authority to add and delete users.

Users can use the system to upload or download their files or documents.

2.4 Operating Environment

2.4.1 Hardware Requirements:

Processor: Pentium G or above.

RAM: Minimum 1 GB.

Standard Keyboard and Mouse.

2.4.2 Software Requirements:

 Operating System: Windows 7 and above.

 Java jdk1.7.0  Eclipse  Tomcat 5.0/6.X  MySQL Server User 0 Graphical Authentication System Graphical Password User Files

(7)

2.5 Design and Implementation Constraints

2.5.1 Input Design: This involve:

 Input to the front end of the system is designed to be the graphical password.

 User photos are used instead of typing user name while login process.

2.5.3 Control Design: Controls provide ways to:

 Registration is mandatory before login.

2.6 User Documentation

In this software, we prepare an about page so that the user can read it and can execute the software properly. It can be seen at top of the Menu page labelled ‘About’. This page will helps the users to work the software.

2.7 Assumptions and Dependencies

There are many dependencies and assumptions associated with the software. They are:

 Every user is expected to have a valid graphical password.

 The size of the files uploaded should not exceed the limit.

3. External Interface Requirements

3.1 User Interfaces

The interface between user and the system include many provisions from where they can access the whole system. It contains the option list to move one form to another as well as searches form that is as follows:

 Login/sing up page

 Generate graphical password page

 File Management Page

4. System Features

Graphical Password Authentication System is a system in which a graphical password is used to authenticate the user and provide them a secured platform to upload or download their files. The system allows the user to upload their files and to download them integrated with security. This project

(8)

has GUI based interface that will help in generating graphical password. This project has a web based interface that will user to upload or download their files.

Use Case Diagram

User Registration Generate Graphical Password Login Upload data with integrated Security Download Data Logout <<include>> <<include>>

(9)

4.1. Graphical Password Generation

4.1.1 Description and Priority

A Unique graphical password (key) is randomly generated by the system in order to remove collision. The key is used for authenticating users.

4.1.2 Functional Requirements

FREQ-1: System should provide a window for graphical password generation. FREQ-2: System should be able to save the generated graphical password.

4.2 User Login

4.2.1 Description and Priority

Only authorised users are able to access the system. The users can be given authorization only by the administrator. This is to ensure security to the system.

4.2.2 Functional Requirements

FREQ-1: System should provide a login form.

FREQ-2: System should provide necessary validation for input data. FREQ-3: System should respond with appropriate messages.

4.2.3 Non-Functional Requirements

NFREQ-1: User images should be securely stored.

4.3Uploading file with integrated security

4.3.1 Description and Priority

User can upload their files into the system with or without integrated security. Security is provided using graphical password technology.

4.3.2Functional Requirements

FREQ-1: System should provide a window to upload the file.

FREQ-2: System should integrate security depending on the user choice using the same graphical password.

(10)

4.3.3 Non-Functional Requirements

NFREQ-1: File uploaded should be saved with encryption.

4.4 Downloading file

4.4.1 Description and Priority

The uploaded file can be downloaded according to the wish of the user. If the uploaded file is integrated with security then then user has to provide the graphical password for authentication..

4.4.2Functional Requirements

FREQ-1: System should provide a window for downloading the file.

FREQ-2: System should authenticate the user using the graphical password provided by the user to clear the security.

4.3.3 Non-Functional Requirements

NFREQ-1: File download should be fast.

5. Other Non-functional Requirements

5.1 Performance Requirements

The performance of the system lies in the way it is handled. Every user must be given proper guidance regarding how to use the system. The other factor which affects the performance is the absence of any of the suggested requirements.

5.2 Safety Requirements

To ensure the safety of the system, perform regular monitoring of the system so as to trace the proper working of the system. An administrator should be there to ensure the safety of the system. He has to be trained to handle extreme error cases.

5.3 Security Requirements

Any unauthorized user should be prevented from accessing the system.

5.4 Software Quality Attributes

1. Planned approach towards working: - The working in the system will be well planned and

(11)

2. Accuracy: - The level of accuracy in the proposed system will be higher. All operation would be

done.

3. Reliability: - The reliability of the proposed system will be high due to the above stated reasons. The

reason for the increased reliability of the system is that now there would be proper storage of information.

4. No Redundancy: - In the proposed system utmost care would be that no information is repeated

anywhere, in storage or otherwise. This would assure economic use of storage space and consistency in the data stored.

5. Immediate storage of information: - In manual system there are many problems to store the largest

amount of information.

6. Easy to Operate: - The system should be easy to operate and should be such that it can be developed

within a short period of time and fit in the limited budget of the user.

5.5 Business Rules

This Graphical password authentication system is having priority role in keeping the secrecy of user. It helps in storing important files or documents in a manner nobody can directly access. Thus the project is having a big scope and space in today’s society.

6. Other Requirements

The registration of new users require the following personal details

 Name  Email  Contact No.  Gender  Mobile No.  Date of Birth

Appendix A: Glossary

 SRS: Software Requirement Specification

(12)

 ADMIN: Administrator

 FREQ: Functional Requirement

 NFREQ: Non Functional Requirement

Appendix B: Analysis Models

Level 1 DFD:

User 2.0 Login Authentication 3.0 File Management

Credentials Graphical Password

Graphical Password Download/Upload request 1.0 Registration Data Storage Personal Files Response Response

(13)

Level 2 DFD:

3.0 File Management User 3.2 Download Authentication Graphical Password Gra ph ica l Pas swor d User Files User F ile s

User Files User Files

3.1 Upload System

(14)

Hierarchical Representation

Graphical

Password

Authentication System

User Register Select Graphical Password Login Upload Files Download Files Logout

Figure

Updating...

References