This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
In normal authentication method the user has to give the user name and the alphanumeric password. Graphical password works same as alphanumeric password the user has to enter the name and the password, but the password will be images. The user has to click on the image in sequences. The sequences of click will become the password. By using the images the user can easily identify password. The steps involved during authentication are Step 1: On logging in the user has to give his/her user name.
Step 2: The user has to click on the particular image which he/she selected as password during registration .
Step 3: The sequences of the click has to be the same as the user click during registration.
Step 4: The sequences of click is noted and checked with the data base.
Step 5: The user is authenticated, if the correct sequences is given.
Step 6: If not authenticated the user has to go thought the authentication process again.
Text-based username and password is vulnerable to guessing, dictionary attack, key-loggers, shouldersurng and social engineering . As mentioned before, to overcome the shortcomings of text-based password, techniques such as two-factor authentication and graphical password have been employed.
Figure 4.1: Simple graphical password
Table 4.1: Comparing the security of graphical and text-based passwords
In most of the schemes, graphical password employs graphical presentations such as icons, human faces or custom images to create a password . Graphical password techniques can be classied into two categories: recognition-based and recall-based . In recognition-based systems, a series of images are presented to the user and a successful authentication requires a correct images being clicked in a right order. In recall-based systems, the user is asked to reproduce something that he or she created or selected earlier during the registration. These methods assume if the number of possible pictures is sufciently large, the possible password space of a graphical password scheme may exceed that of text-based password and therefore it is virtually more resistance to attacks such as dictionary attacks. Also, from the usability standpoint, the graphical password claims to be superior to textbased password due to the fact that humans can remember pictures better than text. Since the graphical password is not widely deployed in real systems vulnerabilities of graphical passwords are still not fully understood. However there are a handful of research papers on this subject that we have summarized their results in Table 1.
Multi-factor authentication is supposed to deliver a higher level of security assurance. For example business networks may require users to provide a password and a random number from a security token to pass the authentication. Knowing the password and having the security token at the same time provides a higher degree of conrmation about the identity of a person. However, the two-factor authentication raises some new challenges, especially in the area of usability. One of the usability challenges is that twofactor authentication is not standardized. There are a handful of dierent authentication factors with various implementations. At the same time, the same authentication factor employed by dierent institutions is not necessarily interoperable. As the result, usually users are expected to remember dozens of unique passwords and carry multiple physical items as the second authentication factor. Cell phone is such a popular technology that it is safe to assume nowadays almost everybody carries a cell phone. Embedded technologies such as RFID, GPS, Bluetooth, pointing and touching sensors, digital cameras, and image and voice recognition oer new applications for cell phones to go beyond voice communication. As a result, cell phones are quickly taking over many personal computing tasks, among them authentication. As a matter of fact, an emerging authentication technologies based on cell phones are appearing which transforms the cell phone into an authentication device by using SMS messaging or an interactive telephone call.Using cell phone in such a way eliminates the need for a separate hardware token which in turn positively impacts the usability of the authentication scheme. Contrary to previous approaches, we employ a cell phone as the second factor of authentication in conjunction with graphical password. This enhances the overall scheme and strengthens the entire authentication process against known types of attacks. Our work is unique because it is the rst to leverage graphical password as a second factor for authentication. In addition, our method can eectively address the guessing and shoulder-surng issue of other image-password methods. Before delving into more details about our systems, we introduce the terminology used for the rest of the paper.
For our approach, the user's handheld is a computing resource that can be conveniently be carried in the user's pocket. In some of our communication scenarios, the handheld device is used to store cryptographic keys and execute encryption-related calculations. Additionally, the handheld must be capable of displaying graphical images. Although we use cell phones for our implementation, for the sake of generality, in the rest of this paper, we will refer to the term handheld meaning any mobile device that is equipped with a display. We will also dene a challenger to be a typical online service provider. The challenger oers potential authentication mechanisms to the user. To be authorized and gain access to resources, the user has to successfully complete one of the presented authentication mechanisms. On the other hand, by Terminal, we refer to the computing resource with a graphical screen and pointing input device or touchscreen capability. This is the device that that user uses to reach to the services provided by the Challenger. The Figure 4.2: A password image and its corresponding key Points terminal can be public or private. Using the public terminal might be riskier but the nature of threats on both public and private terminals are the same. The authentication comes in the form of two images. The rst image is the password image which is sent to the user's terminal as a challenge for password. The password image can be plain or encrypted. The password image is encrypted, if and only if it contains some information about click points. In this case the password image and key image are identical. Key image is a copy of password image which is always encrypted and signed by challenger and can be validated and decrypted on user's handheld device. The key image contains enough information to show the click spots to the owner of handheld. There are some clickable areas in the password image. The user's password is the click points and their order. The click points are clickable areas in the password image which a user can identify them by looking at the key image. The click points and their order are either highlighted in the key image or the user can determine them with some prior knowledge. To make guessing the password more dicult, the number of clickable areas in the password image might be more than the click points. Figure 2.2 shows an example of password images and the corresponding key images prior to encryption or after decryption.
4.3 Communication Alternative
In the public terminal, the user receives and the screen displays a random password image with multiple clickable areas on terminal screen. At the same time, the key image with information about click points appear on the screen of user's handheld which is linked to the identity of the user. Therefore the user learns about the click points and their order if and only if she has access to her handheld. There are several ways to transfer the encrypted password image to the user's handheld which are explained in the followings.
4.3.1 Direct Communication
The challenger sends a password image to the terminal. At the same time, the challenger prepares the key image, encrypts it, digitally signs the encrypted image and emails it to the user's handheld. The user's handheld veries the signature and decrypts the image. For every authentication, the key image changes but the password image may or may not change. Figure 2.3 illustrates the transactions between challenger, terminal, handheld and the user in this method.
4.3.2 Photographic Communication
The challenger prepares a key image, encrypts it and sends it to the user's terminal. Using the handheld's camera, the user takes a photo of the encrypted key image which the handheld can decrypt it. At this point the user is able to click on the appropriate spots on the password image. The image on the screen remains unencrypted and doesn't match what the user sees on the handheld. However what is important here is the click points and not the actual image. Figure 3 illustrates the transactions between challenger, terminal, handheld and the user in this method.
4.3.3 Indirect Communication
Similar to method 2, the challenger prepares a key image, encrypts it and sends it to the user's terminal. The user's handheld and terminal are able to communicate via Bluetooth or USB and transfer a copy of the password image to the handheld and decrypt it. At this point, the user is able to click on the appropriate spots on the password image. The image on the screen remains unencrypted and doesn't match what the user sees on the handheld. Again, what is important here is the click points and not the actual image. Figure 4 illustrates the transactions between challenger, terminal, handheld and the user in this
4.4 Overview Of Praposed System
Graphical password schemes are the alternative to the alphanumeric or text based password system. The simplicity to remember graphical passwords is the advantage of this over normal text passwords. Consider a situation where we want to perform some web-services online. The user is starting the normal login procedures at his/her desk computer and the coworkers may see the computer and observing the graphical password. This emphasis that the existing graphical password system is vulnerable to shoulder surng attack. Later passpoints are introduced; where passwords are the selection of certain areas in the 2D scene. It started with the user to select a predened area on
Figure 4.3: Challenger-Handheld Direct Communication
Figure 4.4: Challenger-Handheld Photographic Communication
Figure 4.5: Challenger-Handheld Indirect Communication digital images. Similarly pass objects make up with invisible boundaries and get authenticated. All these graphical password systems provide a limited password space and vulnerable to shoulder surng attacks. Other 3D graphical password systems are compromising recognition-based, recall-based and tokenbased graphical password systems. In which the user is about to choose any of the authentication mechanism virtually. Depending upon the choices it also making burden to remember a password or text, remember the exact dimension of the secret draw and passpoints. The proposed system is completely three-dimensional and creating an eective password space over 2D.The idea behind the proposed 3D graphical password system is, Passactions where the user does a set of actions on a 3D virtual environment. These actions are recorded, encrypted and stored by using watermarking for authentication. The proposed method has 3 phases password creation, password storage and password verication.
Chapter 5 Methodology
Forty experienced computer users participated in the study. The mean age of the participants was 32.9 years (SD = 10.9), and the range was from 20 to 55 years. The sample included 23 males and 17 females.
The system included both graphical and alphanumeric password interfaces. The PassPoints system was instrumented for data collection. The graphical password interface consisted of an image for inputting the password and several buttons . A single image was used in this experiment. It showed a scene of a hotel swimming pool with people moving around it. The colorful image had many objects that could serve as memorable click points.The rest of the interface consisted of a background with ve buttons and with empty space to present instructions in the experiment. The Submit button was used to submit the password when the user had entered it. The Clear button erased all password points input so far. The Undo button erased only the user's most recent point. The See My Password button allowed the users to view their password during the learning phase and under certain circumstances in the retention phase. The Quit button allowed a user to quit the experiment. All instructions for the participants were given on the screen and feedback on correctness of a password input was given on screen when the user clicked the Submit button. The online testing system also included
Figure 5.1: Graphical password interface used in experiment
a questionnaire that asked the user's perceptions of the password system. In the alphanumeric interface a typical password input eld was shown in which the user typed a password. The buttons were Clear, Submit, Show My Password, and Quit.
A single PC with a high resolution 19 inch monitor was used in the experiment. Testing was done individually. Participants were randomly assigned to the graphical or alphanumeric condition. Each individual participated in three sessions. The rst session lasted about 35 minutes. First, the participants were explained the procedures of the experiment Then they chose a graphical password, given instructions on the screen. Graphical password users had to select and enter ve distinct points on the picture with no point within the tolerance around any other chosen point. They were told that they would have to remember the points and the order in which they were input. Alphanumeric users had to enter eight characters including at least one upper case letter and one digit. They were also told not to choose a password they had already used. The system enforced that the participants re-enter the password until they chose a valid password. A graphical password of 5 points was used based on our analysis (Wiedenbeck et al., 2005) , which shows that in terms of security 5 click points provide a password space as large as or larger than an alphanumeric password of 8 characters. When the participant had created a valid password, the password was displayed as feedback to the participant before going on to the next phase. In the learning phase the participants entered the password repeatedly until they achieved ten correct password inputs. They received binary feedback on the correctness of each password input. If at any time during the practice participants were not able to remember the password, they could click on Show My Password. After the learning phase, the participant lled out the questionnaire online. This was designed to gather user perceptions and act as a distractor between the learning phase and the rst retention trial. In the retention phase, password retention was measured longitudinally three times: at the end of the rst session (R1), one week later (R2), and four weeks later (R3). In these retention trials the participants had only to enter their passwords correctly one time. If the participant entered an incorrect password, the system instructed the participant to re-enter the password. If the participant failed to input the password correctly after four attempts, the Show My Password button was enabled and the participant could view the password, then make another attempt. After the last retention trial, R3, the user again lled out a questionnaire as in the rst session and wrote answers to ve open-ended questions.
5.4 Design Of Passpoint
5.4.1 Background on Graphical Password Systems
Here we discuss some graphical password systems based on recognition or cued recall of images. Most existing systems are based on recognition. The best known of these systems are Passfaces (Brosto & Sasse, 2000; Real User Corporation, 2001) and DØj Vu (Dhamija & Perrig, 2000). Brosto and Sasse (2000) carried out an empiricial study of Passfaces, which illustrates well how a graphical password recognition system typically operates. To create a password, the user chose four images of human faces from a portfolio of faces. To log in the user saw a grid of nine faces, which included one face previously chosen by the user and eight decoy faces. The user had to click anywhere on the known face. This procedure was repeated with dierent target and decoy faces, for a total of four rounds. If the user chose all four correct faces, he or she successfully logged in. Data from this study suggest that Passfaces are more memorable than alphanumeric passwords. A small study of the use of DØj Vu came to the same conclusion. On the other hand, passwords based on image recognition have a serious disadvantage. Only a small number of faces can be displayed on each screen, e.g., in Passfaces nine faces. An attacker has a 1-in-9 chance of guessing this passface. Consequently, the login process requires repetitive rounds of face recognition. If four rounds are used the chance of guessing the password With a few thousand random guesses an attacker would be likely to nd the password. To increase security similar to that of 8-character alphanumeric password, 15 or 16 rounds would be required. This could be slow and annoying to the user. Blonder-style passwords are based on cued recall. A user clicks on several previously chosen locations in a single image to log in. As implemented by Passlogix Corporation (Boroditsky, 2002), the user chooses several predened regions in an image as his or her password. To log in the user has to click on the same regions. The problem with this scheme is that the number of predened regions is small, perhaps a few dozens in a picture. The password may have to be up to 12 clicks for adequate security, again tedious for the user. Another problem of this system is the need for the predened regions to be readily identiable. In eect, this requires articial, cartoon-like images rather than complex, real-world scenes.
5.4.2 Design of the PassPoints System
We developed a graphical password scheme based on Blonder's original idea that overcomes its limitations of needing simple, articial images, predened regions, and consequently many clicks in a password. Our scheme: (1) allows any image to be used and (2) does not need articial predened click regions with well-marked boundaries a password can be any arbitrarily chosen sequence of points in the image (Birget, Hong, & Memon, 2003). Complex images can have hundreds of memorable points, so for example, with 5 or 6 click points one can make more passwords than 8-character Unix-style passwords. In order to log in, the user has to click close to the chosen click points, within some set tolerance distance, e.g., within .25 to .50 cm from the user's click point. The tolerance is needed because the user's click point literally is a single pixel, which is too precise for a user to click on successfully. The tolerance, which is adjustable in the system, gives a margin of error around the click point, in which the user's click is recognized as correct. In Wiedenbeck et al. (2005) we compare the password space of PassPoints with alphanumeric passwords, for various parameter settings. The password space is the set of all passwords that are possible for a given password scheme and for a given setting of parameters. For example, for alphanumeric passwords of length 8 over a 64- character alphabet, the number of possible passwords is 1024. In PassPoints if the image size is 1024 x752 (i.e., roughly the full screen), with a tolerance around the click point of pixels, and with passwords consisting of 5 clicks, the password space will have size 2.6 x1016.
3D Virtual Environment System
The eective designing of virtual world increases the probability of number of passwords. The designing phase of this is depending upon the requirements and security features of the system. In proposed virtual world system a three be [1...G] [1...G] [1...G]. The virtual objects are scattered over the virtual world and each will be having their own properties. It is important to specify the properties of the objects at the 3D environment design. The individual object constitutes a single pixel or a number of pixels to represent it. Every object coordinates (x,y,z) will be point out particular location in the virtual world. The things to be considered is
Physical world to virtual world correspondence : The physical to virtual world correspondence denes a single common space, where an action taken by an end-user aects objects within the virtual world and where any activity by objects in the virtual world aect the end-user's view. This is same as we are performing with real time object in real world. The original world space is represented using a virtual environment.
Virtual uniqueness and the type of the objects : Every virtual object or item in the 3-D virtual environment is dierent from any other virtual object. The uniqueness comes from the fact that every virtual object has its own attributes such as position, size and properties. Thus, the prospective interaction with object 1 is not equal to the interaction with object 2. However, having similar objects such as 20 computers in one place might confuse the user. Therefore, the design of the 3- D virtual environment should consider that every object should be distinguishable from other objects. A simple real-life example is home
numbering. Assume that there are 20 or more homes that look like each other and the homes are not numbered. It would be dicult to distinguish which house was visited a month ago. Similarly, in designing a 3-D virtual environment, it should be easy for users to navigate through and to distinguish between objects. The distinguishing factor increases the users recognition of objects. Therefore, it improves the system usability.
6.1 Implementation Details
In this, a simple 3D virtual environment having large password space since all the items inside the virtual environment is moving. Therefore, to ensure high user acceptability, the user's freedom of selection of items is important. The function f is determined from the object type. It counts the possible actions and interactions can be performed with the object. For example the black board of size n m located in object space (x0, y0, z0) of type textual password will respond as we were writing on it, f will count the possible locations where we can be write, which is around (n*m) possibilities. As we mentioned before, an object type is one of the important factors that aects the overall password space. Therefore, higher outcomes of function f mean larger 3-D password space size. From the previous equations, we observe that the number of objects and the type of actions and interactions determines the probable password space. Therefore, the design of the 3- D virtual environment is a very critical part of the 3-D password system.
6.2 Alogorithm For Praposed System
The proposed system can be implemented with three stages. The initial stage is the predominant one, which requires intense use with the objects in the environment. The 3D virtual environment must be responsive enough to set the password. The real life situations will be having high responsive rate as it is using every day and it won't be a forgettable one. The three stages of this algorithm are Password creation stage, Password storage case and password verication stage. The explanation is given below.
Figure 6.1: 3D password creation image
6.2.1 Password Creation Stage
The user is asked to select the virtual environment, which is familiar to the user. It is selected from the virtual environment gallery of server.
As shown in g:3.1 the user has to perform sequence actions and interactions with the selected objects in the virtual environment. These details regarding selected object will be recorded. A new linked list is created in which each node will contain data for one object.
This sequence of value is used as the graphical password for the user.
6.2.2 Password Storage Stage
MD5 algorithm is used for the authentication purpose. The linked list is stored in a buer where padding and appending is done to make its length 128 bits.
128-bit sequence is generated by MD5 algorithm
User selects an object in the virtual environment, where password can be stored.
As user click on store the password, the 128-bit sequence generated by MD5 is watermarked with the object selected by the user.
Figure 6.2: Password Varication
6.2.3 Password Verication Stage
The user should select the same virtual environment that has been chosen at the registration time.
User selects an object in the virtual environment, where password was stored and extracting from the object.
The user needs to repeat the same sequence of users actions and interactions towards the selected object in the virtual environment 3D for making the password.
This new linked list link list is appended and padded to send as an input for MD5 algorithm.
The new MD5 128 bit string is compared to the 128 bit MD5 value is extracted from the object as shown in g: 3.2. If there is any matching the login will be successful.
6.3 Experimental Results
The virtual library shown in the gure 3 having shelves and books. From this 3D environment we can take and return the books which are needed. It can be extended to support automatic library functions for increasing the password space of the system. Here shows the importance of alternative 3 D environments.
Figure 6.3: virtual environment having shelves, books and pillow
6.4 Purpose and Objective
The purpose of this research study is to develop a graphical password recognition system that will keep track of the authenticity of the user of a particular computer system or particular information system and to improve the accuracy, easily remember and hard to hack or guess. The objectives of the system based on functional requirements include the following:
To enable users to enroll images into the system: The system, after implementation, will be capable of enrolling images to select the click point, areas and set of images. This will be used in detection testing as well as recognition testing of sample templates with dierent face test subjects.
To provide images and motion tracking: Also the system, can provide the tracking images to password with the help of 3D images. We select the object in image after moving from one to another place in 3 D images, also we select the path of the images. Hence the password will be detected while in motion using motion tracking module.
To enable auto recognition: The system will be capable of verifying the user currently using the system. If the user is not the same user who logged in to the particular user account, the system will logs o the system automatically.
To improve the accuracy of password recognition: The accuracy of password detection and password recognition will be improved by various image enrollment. The use of eective algorithms will help to improve the accuracy and the condence level.
6.5 System Scope
The three dimensional password (3D password) is a new authentication methodology that combines recognition, recall, what you have (tokens), and what you are (biometrics) in one authentication system. The idea is simply outlined as follows. The user navigates through a three dimensional virtual environment. The combination and the sequence of the user's actions and interactions towards the objects in the three dimensional virtual environment constructs the user's 3D password. Therefore, the user can walk in the virtual environment and type something on a computer that exist in (X1, Y1, Z1) position, then walk into a room that has a white board that exist in a position (x2, y2, z2) and draw something on the white board. The combination and the sequence of the previous two actions towards the specic objects construct the user's 3D password. Users can navigate through a three dimensional virtual environment that can contain any virtual object. Virtual objects can be of any type. We will list some possible objects to clarify the idea.
An object can be:
A computer that the user can type in
A white board that a user can draw on
A light that can be switched on/o
Any biometric device
Any Graphical password scheme
Any real life object
Moreover, in the virtual three-dimensional environment we can have two dierent computers in two dierent locations. Actions and interactions with the rst computer are totally dierent than actions towards the second computer since each computer has a (x, y, z) position in the three-dimensional virtual environment. Each object in the virtual three dimensional environment has its own (x, y, z) coordinates, speed, weight and responses toward actions.
6.6 System Descreption
6.7 Three D Password Algorithm
Step 1 Prepare the Textual Password Object in the environment.
Step 2 Accept the Password from the object.
Step 3 Retrieve the user information from the database.
Step 4 Decode the information.
Step 5 Authenticate the Log In Process
Authentication with 3D Password
7.1 Architectural study
This section tell about that how to create 3D password & what are dierent schemes used to form a complete 3d password.. 3D password is multi-factor & multi password authentication scheme. So that many password schemes like textual password, graphical password, biometric, etc. password schemes can be used as a part of 3D password. Choosing of dierent schemes are based on category of user who are going to use this scheme to there system. Fig.3 shows state diagram of 3D password creation.
7.2 Working of 3D password scheme
In 3D password user have to First Authenticate with simple textual password(I.e. user need to provide user name & password) Once authentication successful then user moves in 3D virtual environment, Thereafter a computer with keyboard will be seen on screen. On that screen user have to enter password (textual).which is stored in a simple text le in the form of encrypted co-ordinates(x1, y1, z1). After successfully completion of this authentication, Then user automatically enter into an art gallery, where he/she has to select multiple point in that gallery or he can do some action in that environment like switching button on/o or perform action associated with any object like opening door, etc. The sequence in which user has clicked (i.e. selecting objects) that sequence of points are stored in text le in the encrypted form.
In this way the password is set for that particular user. For selection of
points we have used 3d Quick hull algorithm which is based on convex hull algorithm from design & analysis of algorithms. Next time when user want to access his account then he has to select all the object which he has selected at the time of creating password with proper sequence .This sequence is then compared with coordinates which are stored in le. If authentication successful thereafter access is given to authorized user. 3D password working algorithm is shown in g.4. Which will give the owchart for 3D password creation & authentication process.
7.3 3D virtual environment
In this multi-factor authentication scheme the basic building block used is 3 D virtual environment. 3D virtual environment is created inside a 2D screen, refer g.5. 3D environment is a real time scenario seen by peoples in day to day life which is created virtually in 3d virtual environment. We can use any real time object as a environment like any room or village but for simplicity we suggest to use small environment like room.
For selecting the sequence of objects (i.e. points) we have used a very simple, easy & ecient algorithm called as convex hull algorithm. The 3 d quick hull algorithm is used. & also the points selected are stored in the form of 3d co-ordinate(x, y, z) in a simple text le. Some design guidelines related to 3d environment such
Virtual environment selected in such a way so that it is similar to real life object.
Every object is unique & distinct from other.
Virtual environment size should be considered
7.4 3d virtual environment guidelines
The design of the 3D object virtual environments aects the usability, effectiveness, acceptability of 3D password. The rst step in building a 3 D object password system is to design a 3D object environment that reects the administration needs and the security requirements. The design of 3 D virtual environments should follow these guidelines
Real Life Similarity : The prospective 3D object virtual environment should reect what people are used to seeing in real life. Objects used in Figure 7.1: working of 3d password scheme
Figure 7.2: 5 3D environment under 2D screen
virtual environments should be relatively similar in size to real objects (sized to scale). Possible actions and interactions toward virtual objects should reect real life situations. Object responses should be realistic. The target should have a 3D object virtual environment that users can interact
Object uniqueness and distinction every virtual object or item in the 3D object virtual environment is dierent from any other virtual object. The uniqueness comes from the fact that every virtual object has its own attributes such as position. Thus, the prospective interaction with object 1 is not equal to the interaction with object 2. However, having similar objects such as 20 computers in one place might confuse the user. Therefore,the design of the 3D object virtual environment should consider that every object should be distinguishable from other objects. Similarly, in designing a 3D object virtual environment, it should be easy for users to navigate through and to distinguish between objects. The distinguishing factor increases the user's recognition of objects. Therefore, it improves the system usability.
Three Dimensional Virtual Environment Size A 3D object virtual environment can depict a city or even the world. On the other hand, it can depict a space as focused as a single room or oce. A large 3D virtual environment will increase the time required by the user to perform a 3D object password. Moreover, a large 3D object virtual environment can contain a large number of virtual objects. Therefore, the probable 3D object password space broadens. However, a small 3D object virtual environment usually contains only a few objects, and thus, performing a 3D password will take less time.
Number of objects and their types Part of designing a 3D object virtual environment is determining the types of objects and how many objects should be placed in the environment. The types of objects reect what kind of responses the object will have. For simplicity, we can consider requesting a textual password or a ngerprint as an object response type. Selecting the right object response types and the number of objects aects the probable password space of a 3D object password.
System Importance The 3D object virtual environment should consider what systems will be protected by a 3D object password The number of objects and the types of objects that Have been used in the 3D object virtual environment should reect the importance of the protected system.
7.5 3D password application
A small virtual environment can be used in the following systems like
Personal Digital Assistance
Desktop Computers & laptop logins
7.6 Working of Proposed System
Our proposed system comprises of 9 steps out of which steps 1-3 are registration steps and steps 4-9 are the authentication steps.
Step 1 The rst step is to type the user name and a textual password which is stored in the database. During authentication the user has to give that specic user name and textual password in order to log in.
Step 2 In this second step objects are displayed to the user and he/she selects minimum of three objects from the set and there is no limit for maximum number of objects. This is done by using one of the recognition based schemes. The selected objects are then drawn by the user, which are stored in the database with the specic username. Objects may be symbols, characters, auto shapes, simple daily seen objects etc. Examples are shown in Figure 4.
Step 3 During authentication, the user draws pre-selected objects as his password on a touch sensitive screen (or according to the environment) with a mouse or a stylus. This will be done using the pure recall based methods.
Step 4 In this step, the system performs pre-processing
Step 5 In the fth step, the system gets the input from the user and merges the strokes in the user drawn sketch.
Step 6 After stroke merging, the system constructs the hierarchy.
Step 7 Seventh step is the sketch simplication.
Step 8 In the eighth step three types of features are extracted from the sketch drawn by the user.
Step 9 The last step is called hierarchical matching.
During registration, the user selects the user name and a textual password in a conventional manner and then chooses the objects as password. The minimum length for textual password is L=6. Textual password can be a mixture of digits, lowercase and uppercase letter. After this the system shows objects on the screen of a PDA to select as a graphical password. After choosing the objects, the user draws those objects on a screen with a stylus or a mouse. Objects drawn by the user are stored in the database with his/her username. In object selection, each object can be selected any number of times. Flow chart of registration phase is shown in Figure 6. During authentication, the user has to rst give his username and textual password
Figure 7.3: Some examples of objects shown to the user
and then draw pre-selected objects. These objects are then matched with the templates of all the objects stored in the database. Flow chart of authentication phase is shown in Figure 7. The phases during the authentication like the pre-processing, stroke merging, hierarchy construction, sketch simplication, feature extraction, and hierarchical matching are the steps proposed by Wing Ho Leung and Tsuhan Chen in their paper. They propose a novel method for the retrieval of hand drawn sketches from the database, nally ranking the best matches. In the proposed system, the user will be authenticated only if the drawn sketch is fully matched with the selected object's template stored in the database. Pre-processing of hand drawn sketches is done prior to recognition and normally involves noise reduction and normalization. The noise occur in the image by user is generally due to the limited accuracy of human drawn images. . A number of techniques can be used to reduce noise that includes Smoothing, ltering, wild point correction etc. Here in the proposed system Gaussian smoothing is used which eliminates noise
introduced by the tablet or shaky drawing. or specically in two dimensions
standard deviation of the Gaussian
distribution. In case, if user draws very large or a very small sketch then the system performs size normalization which adjusts the symbols or sketches to a standard size. The Stroke merging phase is use to merge the strokes which are broken at end points. If the end points are not close, then that stroke is considered as open stroke and it may be merged with another open stroke if the end point of one stroke is close to the end point of the other. The strokes are then represented in a hierarchy to simplify the image and to make it meaningful for further phases . In the next step of sketch simplication, a shaded region is represented by a single hyper-stroke. After sketch simplication three types of features are extracted from the user redrawn sketch. These features are hyper stroke features, Stroke features, and bi-stroke features. In the last step of hierarchical matching, the similarity is evaluation the top to bottom hierarchical manner. The user is allowed to draw in an unrestricted manner. The overall process is dicult because free hand sketching is a dicult job. The order in which the user has selected the objects does matter in our proposed system i.e. during the authentication phase, the user can draw his pre-selected objects in the same order as he had selected during the registration phase. So, in this way the total combinations of each password will be 2n 1, 'n' being the number of objects selected by the user as password during the registration phase.
7.7 Comparison of Proposed System with Existing Schemes
Our system oers many advantages over other existing systems as discussed below: Comparing to the Passface system, our system can also be used for those who are face-blind. We have used objects instead of human faces for selecting as password because later on during the authentication phase, the user has to draw his/her password and it is a much more dicult task to draw human faces than simple objects. Also we believe that as compared to human faces, objects are easier to remember which are in daily use. Our system has eliminated the problems with grid based techniques where the user has to remember the exact coordinates which is not easy for the user.
Figure 7.4: Flow chart for Registration Phase Our system just compares the shapes of the objects drawn by the user during authentication.
Our scheme is less vulnerable to Brute force attack as the password space is large. It is also less vulnerable to online and oine dictionary attacks. Since stylus is used, it provides ease to the user for drawing objects and also it will be impractical to carry out dictionary attack. Our scheme is better than Man et al scheme. This is because in his scheme the user has to remember both the objects and string and the code. In our method the user has to remember the objects he selected for password and also the way he has drawn the objects during registration. Comparing to Van Oorschot's approach, our system is more secure since users not only select graphical password but also draw their password, making it dicult to hack. In our proposed system, even if the textual password is compromised, the graphical password cannot be stolen or compromised since the user is also drawing the graphical password. Our proposed system diers from CDS in that the user has to rst select a textual password and then a graphical password, making it more secure. Comparing to Two Step Authentication system, our proposed system works in the same way as Two Step Authentication system i.e the user has to choose a textual password before choosing a graphical password but dierence is that in our system during authentication, after giving the username and textual password, the user has to draw his graphical password which is matched with its stored template drawn by the user during the registration phase. This approach protects from hacking the password and prevents them from launching dierent attacks. Thus our system is more secure and reliable than two step authentication system. As with all graphical based systems our system will also be slow. The normalization and matching will take time. An important issue of our system is that it is somewhat user dependent during authentication. It depends upon the user's drawing ability. Thus, the system may not be able to verify the objects drawn by the user and as a result the actual user may not be authenticated. The possible attacks on graphical passwords are Brute force attack, Dictionary attacks, Guessing, Spy-ware, Shoulder surng and social engineering. Graphical based passwords are less vulnerable to all these possible attacks than text based passwords and they believe that it is more dicult to break graphical passwords using these traditional attack methods. Our System is resistant to almost all the possible attacks on graphical passwords. The comparison of our system to existing schemes and systems in resisting attacks on graphical passwords
Figure 7.5: Flow Chart for Authentication Phase
Java is an programing language whose development environment consisting of a Java Development Kit (JDK) and the Eclipse IDE.
8.1.1 System requirements
To complete the exercises in this tutorial, install and set up a development environment consisting of:
JDK 6 from Sun/Oracle.
Eclipse IDE for Java Developers.
Download and installation instructions for both are included in the tutorial. The recommended system conguration is:
A system supporting Java SE 6 with at least 1GB of main memory.
Java 6 is supported on Linuxfi, Windowsfi, and Solarisfi.
At least 20MB of disk space to install the software components and examples.
8.1.2 Platform independent
Unlike many other programming languages including C and C++ when Java is compiled, it is not compiled into platform specic machine, rather into platform independent byte code. This byte code is distributed over the web and interpreted by virtual Machine (JVM) on whichever platform it is being run.
8.1.3 Java Virtual Machine
Java was designed with a concept of 'write once and run everywhere'. Java Virtual Machine plays the central role in this concept. The JVM is the environment in which Java programs execute. It is a software that is implemented on top of real hardware and operating system. When the source code (.java les) is compiled, it is translated into byte codes and then placed into (.class) les. The JVM executes these bytecodes. So Java byte codes can be thought of as the machine language of the JVM. A JVM can either interpret the bytecode one instruction at a time or the bytecode can be compiled further for the real microprocessor using what is called adjust I in time compiler. The JVM must be implemented on a particular platform before compiled programs can run on that platform.
8.1.4 Java Foundation Classes
When developing a Java program it is important to select the appropriate Java Graphical User Interface (GUI) components. There are two basic sets of components that you will most likely build your Java programs with. These two groups of components are called the Abstract Window Toolkit (AWT) and Swing. Both of these groups of components are part of the Java Foundation Classes ( JFC ).
18.104.22.168 Abstract Windowing Toolkit
The AWT (Abstract Window Toolkit) provides an interface between a Java application and a native windowing system. AWT comprises the event handling system as well as a set of so-called heavyweight GUI components, including the top-level components such as frames and dialogs. It also has a simple set of widgets for use in situations where next level of more sophisticated GUI tools is not available. The Abstract Window Toolkit(AWT) contains numerous classes and methods that allow you to create and manage windows. Although the main purpose of the AWT is to support applet windows, it can also be used to create stand-alone windows that run in GUI environment, such as windows. The AWT classes are contained in the 'java.awt' package. Fortunately, because it is logically organized in a top-down, hierarchical fashion, it is easier to understand and use.
An Overview of the AWT : AWT stands for Abstract Window ToolKit. The Abstract Window Toolkit supports GUI Java programming. It is a portable GUI library for stand-alone applications and/or applets. The Abstract Window Toolkit provides the connection between your application and the native GUI. The AWT provides a high level of abstraction for your Java program since it hides you from the underlying details of the GUI your program will be running on.
AWT features include:
A rich set of user interface components.
A robust event-handling model.
Graphics and imaging tools, including shape, color, and font classes.
Layout managers, for exible window layouts that don't depend on a particular window size or screen resolution.
Data transfer classes, for cut-and-paste through the native platform clipboard.
The AWT components depend on native code counterparts (called peers) to handle their functionality. Thus, these components are often called "heavyweight" components.
AWT has a very old code base. Parts of the code are intermingled with other low-level parts of JDK such as 2D, i18n, and Input Methods. The majority of the AWT code consists of the directories shown below.
src/share/classes/java/awt: Contains public API thoroughly specied in java.sun.com/javase/6/docs/technotes/guides/awt/index.html. To rebuild after a small change, go to make/java/awt. The result is a set of classes regularly packed in rt.jar.
Encapsulates AWT events.
Dispatches events to multiple listeners.
Border layout maneger use North, South, East West, and Center.
Creates a push button control
A blank, semantics-free window.
Creates a checkbox control
Creates a group of check box controls
Creates an on/o menu item.
Creates a pop-up list.
Manages colors inplatform-independent fashion.
A subclass of Component that can hold other components.
Creates a dialog window.
Species the dimentions of an object. width,height.
The ow layout manager positionsleft to right, top to bottom.
Encapsulates a type font.
Creates a standard window that hastitle bar,menu bar
Encapsulates the graphics context to display output in a window.
Describes a graphics device such as a screen printer.
The grid layout manager displays components
Encapsulates graphical images.
Creates a label that displays a string.
Creates a list from which the user can choose.
Creates a pull-down menu.
Creates a menu item.
The simplest concrete subclass of Container.
Encapsulates a Cartesian co-ordinate pair, stored in x and y.
Encapsulates a polygon.
Encapsulates a rectangle
Creates a scroll bar control.
A container provides horizontal or vertical scroll bars
Creates a multiline edit control.
Creates a single-line edit control.
Creates a window with no frame, no menu bar, and no title.
Table 8.1: list of some AWR classes src/share/classes/sun/awt: Contains API that is more volatile and not well documented. This has traditionally not been considered public API. Generally, an application developer should not use it.To rebuild after a small change, go tomake/sun/awt. Changes here may require rebuilding of classes and certain libraries, for example splashscreen and awt.dll.
src/solaris/classes/sun/awt and src/windows/classes/sun/awt: Contains low-level implementation of the AWT Toolkits: XToolkit for X Window-based systems, and WToolkit for MS Windows, and also the headless toolkit. Here you will also nd code for MToolkit, requiring a proprietary Motif library. However, this is considered obsolete and isn't built as part of OpenJDK. For partial rebuilding you should start frommake/sun/awt and/or make/sun/xawt. Classes, awt.dll, and mawt.so will be rebuilt in case of changes. The native parts of the code base are written in C and C++. Most of the code is platform-specic and resides in the corresponding directories:
src/solaris/ orsrc/windows/ src/share/native/sun/awt: Currently only the splashscreen subdirectory is a part of AWT proper. For small changes made here, you can rebuild from make/sun/awt ormake/sun/xawt, depending on the platform.
src/solaris/native/sun/awt: A signicant part of this code was used to build MToolkit. Certain parts of it are still in use, however. To rebuild go to make/sun/awt or make/sun/xawt. Note that some of the code here leads to dead ends! src/solaris/native/sun/xawt Contains a native part of XToolkit, AWT Toolkit for X Windows. It's not a large subsection, since most of XToolkit is written in Java. To rebuild go tomake/sun/xawt.
src/windows/native/sun/windows,src/windows/native/sun/awt_common and src/windows/n A part of the code for MS Windows
The Java Swing provides the multiple platform independent APIs interfaces for interacting between the users and GUIs components. All Java Swing classes imports form the import javax.swing.*; package. Java provides an interactive features for design the GUIs toolkit or components like: labels, buttons, text boxes, checkboxes, combo boxes, panels and sliders etc. All AWT exible components can be handled by the Java Swing. The Java Swing supports the plugging between the look and feel features. The look and feel that means the dramatically changing in the component like JFrame, JWindow, JDialog etc. for viewing it into the several types of window.
The advantages of Swing are :
Consistent look-and-feel - The look and feel is consistent across platforms.
Pluggable look-and-feel - The look and feel can be switched on-the-y.
High-level widgets - the Swing components are useful and exible.
In general, the Swing components are easier to use than similar AWT components
Swing's role Swing is the Java platform's UI it acts as the software to handle all the interaction between a user and the computer. It essentially serves as the middleman between the user and the guts of the computer. How exactly does Swing do this? It provides mechanisms to handle the UI aspects described in the previous panel:
Keyboard: Swing provides a way to capture user input.
Colors: Swing provides a way to change the colors you see on the screen.
The address bar you type into: Swing provides text components that handle all the mundane tasks.
The volume of the music: Well ... Swing's not perfect.
22.214.171.124 AWT vs. Swing
There are, of course, both pros and cons to using either set of components from the JFC in your Java applications. Here is a summary:
Speed: use of native peers speeds component performance.
Applet Portability: most Web browsers support AWT classes so AWT applets can run without the Java plugin.
Look and Feel: AWT components more closely reect the look and feel of the OS they run on.
Portability: use of native peers creates platform specic limitations. Some components may not function at all on some platforms.
Third Party Development: the majority of component makers, including Borland and Sun, base new component development on Swing components. There is a much smaller set of AWT components available, thus placing the burden on the programmer to create his or her own AWT-based components.
Features: AWT components do not support features like icons and tool-tips.
Portability: Pure Java design provides for fewer platform specic limitations.
Behavior: Pure Java design allows for a greater range of behavior for Swing components since they are not limited by the native peers that AWT uses.
Features: Swing supports a wider range of features like icons and popup tool-tips for components.
Vendor Support: Swing development is more active. Sun puts much more energy into making Swing robust.
Look and Feel: The pluggable look and feel lets you design a single set of GUI components that can automatically have the look and feel of any OS platform (Microsoft Windows, Solaris, Macintosh, etc.). It also makes it easier to make global changes to your Java programs that provide greater accessibility (like picking a hi-contrast color scheme or changing all the fonts in all dialogs, etc.).
Applet Portability: Most Web browsers do not include the Swing classes, so the Java plugin must be used.
Performance: Swing components are generally slower and buggier than AWT, due to both the fact that they are pure Java and to video issues on various platforms. Since Swing components handle their own painting (rather than using native API's like DirectX on Windows) you may run into graphical glitches.
Look and Feel: Even when Swing components are set to use the look and feel of the OS they are run on, they may not look like their native counter
8.2 Microsoft DirectX
Is a collection of application programming interfaces (APIs) for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms? Originally, the names of these APIs all began with Direct, such as Direct3D, DirectDraw, DirectMusic, DirectPlay, DirectSound, and so forth. The name DirectX was coined as shorthand term for all of these APIs (the X standing in for the particular API names) and soon became the name of the collection. When Microsoft later set out to develop a gaming console, the X was used as the basis of the name Xbox to indicate that the console was based on DirectX technology. The X initial has been carried forward in the naming of APIs designed for the Xbox such as Input and the Cross-platform Audio Creation Tool (XACT), while the DirectX pattern has been continued for Windows APIs such as Direct2D and Direct Write. The components of DirectX are
DirectDraw: for drawing 2D Graphics (raster graphics). Now deprecated (in favor of Direct2D), though still in use by a number of games and as a video renderer in media applications.
Direct3D (D3D): for drawing 3D graphics.
DXGI: for enumerating adapters and monitors and managing swap chains for Direct3D 10 and up.
Direct2D for 2D Graphics
DirectWrite for Fonts
DirectCompute for GPU Computing
DirectInput: for interfacing with input devices including keyboards, mice, joysticks, or other game controllers. Deprecated after version 8 in favor of XInput for Xbox 360 controllers or standard WM INPUT window message processing for keyboard and mouse input.
There are alternatives to the DirectX family of APIs, with OpenGL having the most features.
8.3 OpenGL (Open Graphics Library)
It is a cross-language, multi-platform API for rendering 2D and 3D computer graphics. The API is typically used to interact with a GPU, to achieve hardware-accelerated rendering. OpenGL was developed by Silicon Graphics Inc. in 1992 and is widely used in CAD, virtual reality, scientic visualization, information visualization, ight simulation, and video games. OpenGL is managed by the non-prot technology
As well as being language-independent, OpenGL is also platform-independent. The specication says nothing on the subject of obtaining, and managing, an OpenGL context, leaving this as a detail of the underlying windowing system. For the same reason, OpenGL is purely concerned with rendering - it provides no APIs related to input, audio or windowing. This is perhaps the greatest dierence between OpenGL and its competitor, DirectX. The OpenGL specication describes an abstract API for drawing 2D and 3 D graphics. Although it's possible for the API to be implemented entirely in software, it's designed to be implemented mostly or entirely in hardware. For example, the Microsoft Windows implementation of OpenGL will perform all of its rendering commands using a GPU, when one is available.
8.4 CUDA (formerly Compute Unied Device
CUDA (formerly Compute Unied Device Architecture) is a parallel computing platform and programming model created by NVIDIA and implemented by the graphics processing units (GPUs) that they produce. CUDA gives developers access to the virtual instruction set and memory of the parallel computational elements in CUDA GPUs. Using CUDA, the latest Nvidia GPUs become accessible for computation like CPUs. Unlike CPUs, however, GPUs have a parallel throughput architecture that emphasizes executing many concurrent threads slowly, rather than executing a single thread very quickly. This approach of solving general-purpose (i.e., not exclusively graphics) problems on GPUs is known as GPGPU. The CUDA platform is accessible to software developers through CUDA-accelerated libraries, compiler directives (such as OpenACC), and extensions to industry-standard programming languages, including C, C++ and Fortran. C/C++ programmers use 'CUDA C/C++', compiled with "nvcc", NVIDIA's LLVM-based C/C++ compiler, and Fortran programmers can use 'CUDA Fortran', compiled with the PGI CUDA Fortran compiler from The Portland Group. In addition to libraries, compiler directives, CUDA C/C++ and CUDA Fortran, the CUDA platform supports other computational interfaces, including the Khronos Group's OpenCL, Microsoft's DirectCompute, and C++ AMP.Third party wrappers are also available for Python, Perl, Fortran, Java, Ruby, Lua, Haskell, MATLAB, IDL, and native support in Mathematica.
read backs to and from the GPU
Texture rendering is not supported
Copying between host and device memory may incur a performance hit due to system bus bandwidth and latency
8.5 Open Computing Language ( OpenCL )
It is a framework for writing programs that execute across heterogeneous platforms consisting of central processing units (CPUs), graphics processing units (GPUs), DSPs and other processors. OpenCL includes a language (based on C99) for writing kernels (functions that execute on OpenCL devices), plus application programming interfaces (APIs) that are used to dene and then control the platforms. OpenCL provides parallel computing using task-based and data-based parallelism. OpenCL is an open standard maintained by the non-prot technology consortium Khronos Group. It has been adopted by Intel, Advanced Micro Devices, NVidia, and ARM Holdings. For example, OpenCL can be used to give an application access to a graphics processing unit for non-graphical computing (see general-purpose computing on graphics processing units). Academic researchers have investigated automatically compiling OpenCL programs into application-specic processors running on FPGAs, and commercial FPGA vendors are developing tools to translate OpenCL to run on their FPGA devices.
8.6 Java With Oracle Database Connectivity
The Java DataBase Connectivity API is a set of classes allowing a straightforward and vendor-neutral access to database management systems. We will review the basic features of JDBC and their use with Oracle
JDBC provides a set of high-level classes that enable anyone acquainted with SQL and Java to write database applications. Considerations