password protector documentation

8/6/2019 Password Protector Documentation

1/34

ABSTRACT

Passwords are the keys to your system. It goes without saying that

they should be as secure as possible to prevent an unauthorized login,

which is the first step to much bigger security problems. Using

passwords that are strong enough to blunt an attack is a crucial yet

simple step that can save you a lot of trouble in the future.

CONTENT


2/34

1. ABSTRACT

2. INTRODUCTION3. DESIGN PRINCIPLES & EXPLANATION

3.1. MODULES

3.2. MODULE DESCRIPTIOIN

4. PROJECT DICTIONARY

4.1. DATAFLOW DIAGRAMS

4.2. E-R DIAGRAMS

4.3. DATA DICTIONARY

5. FORMS & REPORTS

5.1. I/O SAMPLES

6. TESTING

7. BIBILIOGRAPHY

1. ABSTRACT


3/34

Passwords are the keys to your system. It goes without saying that

they should be as secure as possible to prevent an unauthorized login,

which is the first step to much bigger security problems. Using

passwords that are strong enough to blunt an attack is a crucial yet

simple step that can save you a lot of trouble in the future.

2. INTRIDUCTION

Proposed System:

Protect your files and folders with File & Folder Protector at Windows

kernel level. This great easy-to-use password-protected security utility

lets you password-protect certain files and folders, or to hide them

securely from viewing and searching just with a click of mouse. When

PC user tries to access any protected file or folder, dialog box querying

password appears on the screen. If entered password is valid, the user

can access this file or folder, otherwise not. File & Folder Protector

does not modify your media: in protecting your files or folders, it just

uses a high-reliability VXD driver working at Windows kernel level. This

guarantees that File & Folder Protector will never lose your data, asmay happen if you use other file- and folder-protecting software. Due

to unique technology, the program also lets you protect system files

and folders such as the Windows System, Registry and Swap files.

3. DESIGN PRINCIPLES & EXPLANATION

3.1. MODULES


4/34

After carefully analyzing the clients request our team came out with

clear reports and according to which our project can be divided in

modules as follows.

1) GUI Implementation

2) Authentication

4.1. USECASE DIAGRAMS

Login

SecurityAPI

SecurityReferenceMonitor

AccessToken for

userFiles and

foldersMaintainAccess

Control listVerify Access

token inAccess list

Use files andfolders

and level ofaccess

Modify FileAccess

Control list

Admin

Use Case Diagram for Admin


5/34

Login

SecurityAPI


AccessToken for

userFiles andfolders

MaintainAccess


token inAccess list


and level ofaccess

Modify FileAccess

Control list

Login

SecurityAPI


AccessToken for

userFiles andfolders

MaintainAccess


token inAccess list


and level ofaccess

Modify FileAccess

Control list

User

Use Case Diagram for User


6/34

Administrator

Login to the PC

Configure folder and fileprotecting software

Add this Software to the windowsServices

Set the Password to the requiredfolders.

Logout

Context Level Diagram for Admin


7/34

Login

to PC Valid

InvalidAccessTheProtectedFile oFolder

Enter thePassword

ValidPWD

Allow toAccess the

files

Error MSG

Sequence Diagram for users


8/34

Admin

Login

SecurityAPI


Access Tokenfor user

ModifyAccesscontrol List

Use files & folders levelof access

Verify accesstoken

MaintainAccess Control list

Y

N

Logout


9/34

User

Login

SecurityAPI


Access Tokenfor user

ModifyAccesscontrol List

Use files & folders levelof accessVerify access

token

MaintainAccess Control list

Y

N

Logout


10/34

Login

Security API

Security Reference Monitor

Access Token for user

Files and folders Maintain

Access Control list

Verify Access token in Access

list

Use files and folders andlevel of access

Modify File Access

Control list

Admin


11/34

Login

Security API

Security Reference Monitor

Access Token for user

Files and folders MaintainAccess Control list

Verify Access token in Access

list

Use files and folders and

level of access

User


12/34

Activity Diagram for Admin/Users

Verify

Login

Login

Admi

n User

Security

API

SecurityReference

Monitor

Maintain

Access Controllist

Access Token

for user

Security

API

SecurityReference

Monitor

Maintain

Access

Control list

Access Token

for user

ModifyAccess

control

List

Use files &

folders level of

access

Verifyaccess token

Use files &

folders level ofaccess

End

Verify access

token


13/34

Context Level Diagram

Administrator

Login to the PC

Configure folder and file protecting

software

Add this Software to the windows

Services

Set the Password to the required

folders.

Logout


14/34

Use case diagram

Login to the System

Install file-folder protector Software

Configure

the file-folder Software

Set the permissions to the files

or folders

Provide the password to

the authorized users

Logout

Administrator


15/34

Sequence Diagram for users

Login

to PC Valid

Invalid

Access

TheProtected Enter the

File or Password Valid

Folder. PWD

Allow to

Access the

files

Error MSG


16/34

5. I/O SAMPLES

HOME PAGE


17/34


18/34


19/34


20/34


21/34


22/34


23/34


24/34


25/34


26/34


27/34

Testing

Software Testing is the process used to help identify

the correctness, completeness, security, and quality of

developed computer software.

Testing is a process of technical investigation, performed on

behalf of stakeholders, that is intended to reveal quality-related information about the product with respect to the

context in which it is intended to operate. This includes, but

is not limited to, the process of executing a program or

application with the intent of finding errors.

One definition of testing is "the process of questioning a

product in order to evaluate it", where the "questions" areoperations the tester attempts to execute with the product,

and the product answers with its behavior in reaction to the

probing of the tester. A good test is sometimes described as

one which reveals an error; however, more recent thinking

suggests that a good test is one which reveals information of

interest to someone who matters within the projectcommunity.

In general, software engineers distinguish software faults

from software failures.


28/34

In case of a failure, the software does not do what the user

expects.

A fault is a programming error that may or may not actually

manifest as a failure.

A fault can also be described as an error in the correctness

of the semantic of a computer program.

A common practice of software testing is that it is performed

by an independent group of testers after the functionality is

developed but before it is shipped to the customer.

Another practice is to start software testing at the same

moment the project starts and it is a continuous process

until the project finishes.

White-box and black-box testing

White box and black box testing are terms used to

describe the point of view a test engineer takes when

designing the test cases.

Black box being an external view of the test object and

white box being an internal view. Software testing is partly

intuitive, but largely systematic. Good testing involves much

more than just running the program a few times to see

whether it works.

Software Testing is the process of executing software in a

controlled manner; in order to answer the question Does

this software behave as specified?


29/34

Software testing is used in association with Verification and

Validation.

Verification is the checking of or testing of items, including

software, for conformance and consistency with an

associated specification. Software testing is just one kind of

verification, which also uses techniques as reviews,

inspections, walk-through.

Validation is the process of checking what has been specified

is what the user actually wanted.

Validation: Are we doing the right job?

Verification: Are we doing the job right?

In order to achieve consistency in the Testing style, it is

imperative to have and follow a set of testing principles.

Three phases of testing in Software Development Life Cycleare:

Unit Testing: in which each unit (basic component) of

the software is tested to verify that the detailed design

for the unit has been correctly implemented

Integration Testing: in which progressively larger

groups of tested software components corresponding to

elements of the architectural design are integrated and

tested until the software works as a whole.


30/34

System Testing: in which the software is integrated to

the overall product and tested to show that all

requirements are met

A further level of testing is also done, in accordance with

requirements:

Acceptance Testing: upon which the acceptance of

the complete software is based. The clients often do

this.

Regression Testing: is used to refer the repetition of

the earlier successful tests to ensure that changes

made in the software have not introduced new

bugs/side effects.

Test levels

Unit testing tests the minimal software component and

sub-component or modules by the programmers.

Integration testing exposes defects in the interfaces

and interaction between integrated components

(modules).

Functional testing tests the product according to

programmable work.

System testing tests an integrated system to

verify/validate that it meets its requirements.


31/34

o Acceptance testing testing can be conducted by

the client. It allows the end-user or customer or

client to decide whether or not to accept the

product. Acceptance testing may be performed

after the testing and before the implementation

phase

After modifying software, either for a change in functionality

or to fix defects, a regression test re-runs previously passing

tests on the modified software to ensure that themodifications haven't unintentionally caused a regression of

previous functionality. Regression testing can be performed

at any or all of the above test levels. These regression tests

are often automated.

Test cases, suites, scripts and scenarios

A test case is a software testing document, which consists of

event, action, input, output, expected result and actual

result.

This can be as pragmatic as 'for condition x your derived

result is y', whereas other test cases described in more

detail the input scenario and what results might be

expected. It can occasionally be a series of steps but with

one expected result or expected outcome. The optional fields

are a test case ID, test step or order of execution number,


32/34

related requirement(s), depth, test category, author, and

check boxes for whether the test is automatable and has

been automated. Larger test cases may also contain

prerequisite states or steps, and descriptions. A test case

should also contain a place for the actual result. These steps

can be stored in a word processor document, spreadsheet,

database or other common repository.

The term test script is the combination of a test case, test

procedure and test data.

The most common term for a collection of test cases is a

test suite. The test suite often also contains more detailed

instructions or goals for each collection of test cases. It

definitely contains a section where the tester identifies the

system configuration used during testing. A group of test

cases may also contain prerequisite states or steps, and

descriptions of the following tests.


33/34

A Testing Cycle

1. Requirements Analysis: Testing should begin in the

requirements phase of the software development life

cycle.

During the design phase, testers work with developersin determining what aspects of a design are testableand under what parameter those tests work.

2. Test Planning: Test Strategy, Test Plan(s), Test Bed

creation.

3. Test Development: Test Procedures, Test Scenarios,

Test Cases, Test Scripts to use in testing software.

4. Test Execution: Testers execute the software based

on the plans and tests and report any errors found to

the development team.

5. Test Reporting: Once testing is completed, testers

generate metrics and make final reports on their test


34/34

effort and whether or not the software tested is ready

for release.

6. Retesting the Defects

7. BIBILIOGRAPHY

The following books and manuals provided a lot of help to us in

making this project a reality.

1. The Complete reference ASP.Net (Tata McGraw Hill)

2. The Complete reference ASP

3. Internet and world wide web- How to program in ASP.Net? (Dietel

and Dietel and Nieto)

4. Principles of Software Engineering 4th edition (Ian Somerville)

5. Software Engineering- A Practitioners Approach (Roger S.

Pressman)

6. System Analysis & Designing ( James A. senn, Tata McGraw Hill)

password protector documentation

Documents