ArticlePDF Available

Abstract and Figures

One of the most popular aids adopted by users to reduce the pain suffered from the use of passwords is browsers' autocomplete feature. This feature, caching username and password after getting the user consent and using them later for automatic completion, is available in all modern browsers but communication with the user asking consent is implemented in different ways. In this paper, we report on user studies comparing active communication with a blocking dialog box and passive communication with a non-intrusive toolbar. We found that a dialog box misled users to save passwords in public computers. Conversely, no security problem was observed with passive communication. Our exploration provides empirical evidence for the risks of preferring active communication for password autocomplete and other similar interactions and sheds light on many other aspects of password autocomplete.
Content may be subject to copyright.
Johnny in Internet Café:
User Study and Exploration of Password Autocomplete in
Web Browsers
Kemal Bicakci
TOBB University of Economics and
Technology
Ankara, Turkey
bicakci@etu.edu.tr
Nart Bedin Atalay
Selcuk University
Konya, Turkey
nartbedin@gmail.com
Hakan Ezgi Kiziloz
TOBB University of Economics and
Technology
Ankara, Turkey
hakanezgi@etu.edu.tr
ABSTRACT
One of the most popular aids adopted by users to reduce the pain
suffered from the use of passwords is browsers’ autocomplete
feature. This feature, caching username and password after
getting the user consent and using them later for automatic
completion, is available in all modern browsers but
communication with the user asking consent is implemented in
different ways. In this paper, we report on user studies
comparing active communication with a blocking dialog box
and passive communication with a non-intrusive toolbar. We
found that a dialog box misled users to save passwords in public
computers. Conversely, no security problem was observed with
passive communication. Our exploration provides empirical
evidence for the risks of preferring active communication for
password autocomplete and other similar interactions and sheds
light on many other aspects of password autocomplete.
Categories and Subject Descriptors
C.2.0 [Computer-Communication Networks]: General-
Security and Protection;
H.5.2 [User Interfaces]:
Evaluation/methodology.
General Terms
Experimentation, Security, Human Factors.
Keywords
Usable security, passwords, user study.
1. INTRODUCTION
Given the growing number of accounts users have passwords for
[4], password management incurs an overwhelming cognitive
load and becomes a herculean task not easily be succeeded
without any aid. One popular aid adopted by users to reduce the
pain suffered is browsers’ autocomplete feature [7].
While many aspects of the password problem have been studied
in the literature (e.g., [4][5][7]), despite its wide adoption up to
our best knowledge no previous study on password
autocomplete has been reported. In this paper, we make a first
attempt towards having a better understanding for the security
risks and usability benefits of this feature. Specifically, the
emphasis in this work is on user interfaces for password
autocomplete and the risks when public computers are in use.
Today, all modern web browsers support password
autocomplete; caching username and password after getting the
user consent and filling fields automatically thereafter. In all of
these browsers, input from the user is asked before the password
is stored because it is not secure to save the password in a
computer not owned by the user. Users are supposed to make the
correct decision. They should choose not to store when the
computer they use is not solely under their control (e.g., public
or borrowed machines), whereas they are free to use this useful
feature when there is no security consequence or when security
risks are relatively smaller (e.g., their own laptop).
Different types and versions of web browsers implement the
password autocomplete feature in different ways. Specifically,
version 8 of Internet Explorer communicate users with a dialog
box which blocks them continuing (Figure 1). On the other
hand, Firefox version 3 applies the non-intrusive toolbar
approach (Figure 2). The main research question we investigate
in this paper is whether the aforementioned implementation
choice has an impact on taking the right decision of not saving
passwords on public computers. Besides this central focus, our
study pursues a number of other usability issues surrounding the
password autocomplete feature. For these purposes, we
conducted a series of user studies and reported on the results. In
summary, we found that non-intrusive toolbar approach provides
a significantly more secure user experience. We argue that our
results can be generalized to similar interface problems, and
hence we conclude that secure interaction designers should think
twice before choosing active type of communication if simply
neglecting the message does not pose any security threat.
The rest of our paper is organized as follows: Section 2
summarizes related work. Section 3 provides more information
on password autocomplete feature. Section 4 presents the
method and results of our usability studies. Section 5 provides a
general discussion of the results. Section 6 concludes the paper.
2. RELATED WORK
Being a weak link in the security chain and becoming a real
nuisance for users, passwords have always been an important
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
DIM’11, October 21, 2011, Chicago, IL, USA.
Copyright 2011 ACM 1-58113-000-0/00/0010…$10.00.
target for security research [10]. Fueled by the usability and
security problems of passwords, a recent surge of research on
this area has also been triggered (e.g., [9]). Today, we know
many things about passwords; users generally choose weak
passwords [4], they reuse their passwords over several accounts
[5], etc. However we have not found any prior work on
password autocomplete feature despite its common use in
practice [7]. Below, we provide a summary of previous work
related to this topic in a more general context.
The conceptual framework proposed by Cranor [2] is useful to
identify problems when secure systems rely on a “human in the
loop” to perform security-critical functions. Cranor argued that
security decisions should be made by the system automatically
whenever possible so that error-prone users are taken out of the
security loop. However cases do exist for which this
recommended best practice is not applicable [2] [19]. When a
system should rely on user decisions to perform a security-
critical function, communication with the user can be placed
anywhere on a spectrum, ranging from active i.e., by
interrupting user’s primary task to passive i.e., available to users
but can easily be ignored.
Less intrusive approaches are already considered to be more
suitable in a number of situations. To exemplify; asking users to
install a software in Firefox [15] and pop-up blocking in Internet
Explorer (with Windows XP service pack 2) [11] is preferred to
be presented to users in a non-intrusive toolbar. This is accepted
as a good compromise and right balance between security and
convenience [15]. It was acknowledged that if an intrusive
dialog box is used instead to notify users, being conditioned to
ignore such messages [6] [11] users want to dismiss the message
in the quickest way possible [15]. Consequently, this habituation
may lead to security breaches. On the other hand, the
investigation on password autocomplete feature in this paper
clearly shows that this user interface design principle has not
been applied consistently throughout all browsers types and all
relevant security interactions.
Figure 1. User is expected to click on “AutoComplete Passwords” dialog box to be
able to continue with his task in Internet Explorer
8
.
Figure 2. Password Autocomplete does not interrupt user’s task with “Remember the
Password” toolbar in Firefox 3.5 (in this example login attempt failed).
Guttman provides a nice overview of usability problems in
security domain [6]. Particularly, the section on user
conditioning (pages 70-75) is provoking. According to him,
“Like Pavlov’s dogs, users quickly learn that clicking the close
or cancel button allows them to continue doing what they want
to do”.
On the other hand, passive communication is not appropriate in
a number of situations. For instance, Dhamija et al. showed that
passive security indicators are ineffective against phishing
websites hence not recommended [3].
3. PASSWORD AUTOCOMPLETE
Password autocomplete feature would be the answer to all
usability problems of passwords and free of security problems
under ideal circumstances. In an ideal world where every
Internet user has a single computer they always carry with them
and that computer is reliable (not break down) and secure (no
other person can have an access and there is no malware inside),
then all problems that passwords bring for the Internet would
suddenly go away. Strong passwords could be assigned to users
while they are registering to web sites, these passwords are
stored in browser cache and then the browser automatically
completes all logins thereafter. We note that password
autocomplete feature could even be a solution to phishing
attacks in this ideal world because users become victim of these
attacks mostly because they are being conditioned into
constantly entering passwords [6]. In this ideal world, browser
does not need any user input to give a decision, it simply caches
all passwords by default.
However the real world is far from being ideal. We list some of
the usability concerns in the above scenario in today’s world as
follows:
1. Occasionally, we buy new computers or format hard
drives hence passwords are not always in the cache.
2. Sometimes, we require to login from other computers
hence enter passwords manually (unless we use a
portable browser e.g., Portable Firefox [13]).
3. On the new computer we login, our passwords could
be available to next users unless we took necessary
countermeasures (e.g., manually erasing the
password.).
First two items in the above list are practical usability problems.
Last issue is even more problematic because obviously it also
brings security issues.
One may argue that regardless of password autocomplete
entering passwords on another computer is always dangerous. In
a sense that is true; all needed to capture the password is a
simple keylogger program. However we believe that storing
passwords in browser’s cache significantly increases the security
risk. For instance a small Javascript code executed on the
browser (e.g., Figure 3) is sufficient to view passwords stored
with password autocomplete feature [8].
To deal with the security problems autocomplete brings for
public computers, disabling autocomplete entirely in public
computers (for instance by the system admin of public
computers) is an option but this secure practice is not common
and not always applicable. To mitigate the security risks,
“Private Browsing” mode, available in most browsers, could
also be useful. Password autocomplete is disabled in a “Private
Browsing” mode however our anecdotal observation is that this
mode of operation is also not widely used. Another secure but
not widely adopted practice is the protection of saved passwords
with a master password.
In the web application developer community, the risks of
password autocomplete feature are well-understood. For
instance, Yahoo mail and some Internet banking web sites set
off password autocomplete by putting the command <FORM
autocomplete = "off"> on their web pages
1
[16] (some browser
extensions offer a solution to this inconvenience! e.g., [12]).
The short discussion above explains why all browsers enable
password autocomplete only after communicating with the user
and getting consent. But browsers have different types of
implementation for this communication. If we look specifically
at two most used browsers [1] [17], we see that Internet
Explorer implements blocking dialog box
2
(Figure 1) whereas
Firefox adopts nonintrusive widget (toolbar) approach (Figure
2).
As a summary for this section; password autocomplete is a
useful feature implemented in all modern web browsers but we
should give a consideration of its security risks due to careless
use especially in public computers.
4. USER STUDY
In this study, our main objective is to compare active (intrusive)
and passive (non-intrusive) types of communication for
password autocomplete in web browsers when public computers
are in use. We proposed that blocking users’ action for asking
them question about password autocomplete might lead to
inadvertent storage of passwords whereas non-intrusive
communication does not have such vulnerability. Even though
disadvantage of active (intrusive) communication is evident, at
least for us, there was no empirical study which has investigated
security vulnerabilities of intrusive type of communication for
security decisions.
1
We note that cookie based password avoidance techniques some of
these sites implement have also security implications [16].
2
The latest version of Internet Explorer (version 9) was released on
March 14, 2011. This new version which replaces active (intrusive)
communication with passive one for password autocomplete was not
available while we were conducting our user studies. Version 9 is not
supported in Windows XP, which is still the most popular version of
Windows operating system based on user base [20] and earlier Windows
versions. An additional note is that dialog box approach for password
autocomplete is still preferred in the latest versions of some browsers
(e.g., Safari, fourth most widely used browser [17], version 5).
javascript:
var x=document.getElementsByTagName('input');
myVals='';
for(var i=0;i<x.length;i++){z=x[i].getAttribute('type');
if(z=='password')myVals=myVals+'The password value is:
'+x.item(i).value+('\n\n')};
alert(myVals);
Figure 3. Javascript code to view a password in browser’s
cache [8].
We have chosen Internet Explorer and Firefox as the browsers to
investigate in our study and compared users’ choices of saving
passwords with Internet Explorer version 6 and Firefox version
3. Internet Explorer version 6 (henceforth IE) is no different
than other versions up to 8 in the sense that it communicates
with a dialog box which blocks users continuing with their
login. Firefox version 3 (henceforth FF) and newer versions
communicate with a non-intrusive toolbar. We observed users’
behavior to see whether and when password autocomplete
feature creates security vulnerability in public computers. We
hypothesized that more users would save their password with IE
(when an active - intrusive communication is prompted)
compared to FF.
To test our hypothesis, three different but similar experiments
were performed. We looked at each experiment and its results
with a critical eye and designed the next experiment with some
necessary modifications to address ecological validity concerns
and to explore new arising questions. These experiments are
presented in order under the following subheadings. A general
discussion is provided at the next section.
4.1 Experiment 1
4.1.1 Method
4.1.1.1 Lab and Participants
Our study was conducted in the student-computer lab of Selcuk
University. There were 10 personal computers in the lab, and
each was running Turkish Windows XP (with service pack 2).
IE and FF were already installed on all computers.
Students had been using lab computers for the course named
Introduction to Information Technologies and Applications.
Login to computers was with a generic account requiring no
authentication. Restarting a computer kept all information of the
previous session intact. Every student was aware of the fact that
recording personal information on a computer would make it
available to anybody using that computer. At the time of the
study, participants had been using the computer lab at least for 3
months.
We consulted non-technical students in this study in order to be
able to generalize our results to Internet users who are not
computer experts,. Participants were 27 (16 male and 11 female)
students of Selcuk University, Konya, Turkey. 22 of them were
between 20-30 years old and 5 of them were in a younger age.
The second author (NBA) teaches the ‘Introduction to
Information Technologies and Applications’ course in this lab.
The aim of the course is to introduce basic computer skills, such
as using Windows operating system, browsers, ftp software,
office programs, etc. Before the execution of the study, no
lecture on security and passwords was given.
4.1.1.2 Procedure
The data were collected with a semi-controlled lab experiment.
Before the experiment, any password saved on IE and FF was
deleted and the password autocomplete feature was checked and
set it active if not. Participants were invited to the experiment in
groups (min. 2 and max. 10). Each participant used a computer
in the lab individually. In order to conceal the true aim of
Experiment 1, participants were told that the study investigates
the speed of IE and FF. They were instructed to login to the
student registration web page of Selcuk University, with IE and
FF. The web page contains personal and private information,
such as home address, telephone, cumulative GPA, etc. The
order of browser use was counterbalanced across participants.
To collect their habitual responses, participants were instructed
to finish the task as fast as possible.
After completing the login tasks, participants answered
questions regarding their choices for password autocomplete
options and their knowledge about deletion of saved passwords
on browsers. At the end of the experiment, they were instructed
about the nature of the study. They filled a second questionnaire
on their computer skills and attitudes towards the password
autocomplete feature. Following that, they were given a lecture
on password security.
Experimenter (NBA) checked whether a user saved his/her
password of student registration web page using password
autocomplete feature on IE and FF. Then, saved passwords were
deleted and password autocomplete was set to active in both
browsers to test next group of participants.
4.1.2 Results
4.1.2.1 User Profile and User Knowledge on
Password Autocomplete
Most of the participants rated their computer skills as average or
below average (21 participants, 78%). Most of them were using
Internet on daily basis (18 participants, 67%). Majority of
participants in Experiment 1 prefer using IE in their daily life
(20 participants, 77%). About half of our participants (15
participants, 55%) reported that they knew about password
autocomplete. Among these participants most of them (10 out of
15 participants, 66%) were using it for more than one account.
When we asked whether they knew how to delete saved
password from browsers, only small number of participants
responded affirmatively (7 participants, 26%, for IE; 4
participants, 15%, for FF). On the other hand, only one of them
were able to correctly describe how (i.e., with the Delete
button). Some of the participants believed that deleting browser
history and cookies also erases the saved passwords on a
browser. Another one believed saved passwords are erased
automatically after some time. One participant confused
autocomplete feature with cookie based “Remember me” option
on web pages.
In summary, participants of Experiment 1 were non-expert
Figure 4. Number of participants who saved a
password on IE and FF in Experiment 1.
computer users. About half of them were actively using
password autocomplete while the other half were not aware of it.
Almost all of them did not know how to delete stored passwords
on browsers.
4.1.2.2 Saving Passwords
None of 27 participants saved password on FF, but 8 of them
(~30%) saved their passwords on IE (See Figure 4). The
association between browser type and saving password was
significant
2
(1)=9.39, p < 0.05]. These results showed that the
tendency to save password on a browser increases with the
active (intrusive) dialog box.
We also investigated another important issue, participants'
memory about the option they clicked for password
autocomplete. Among the 8 participants who saved their
password on IE, none of them reported that they clicked to the
option for saving the password (See Figure 5). In other words,
none of the participants who saved password on IE correctly
remembered his/her action. Among the 19 participants who did
not save password on IE, 14 (77%) of them remembered
correctly that they clicked to the one of the options that did not
save password. Interestingly, 2 participants reported that they
saved their password, actually they did not and another 2
participants reported that they did not remember their action.
(One participant did not answer this question.) For FF, among
27 participants, 18 (66%) of them reported that they either did
not recollect their response or they took no action (Response
“None” in Figure 5 covers both options in Experiment 1).
Interestingly, one participant reported that he saved his
password on FF, but actually he did not. These results showed
that regarding the option that they clicked for password
autocomplete participants' memory was poor and this was
especially so when they actually saved it.
4.1.3 Discussion and Limitations
In Experiment 1, we observed that with non-expert computer
users active communication increases the rate of saving
password on a public computer. Users should not save their
passwords on public computers however, 8 out of 27
participants did so in our study when they were confronted with
a pop-up dialog box. This was in contrast to FF on which
nobody stored his/her password with the nonintrusive toolbar.
The significant association between communication type and
password saving behavior confirmed our hypothesis that more
users would save their password on a public computer with
active (intrusive) communication.
In Experiment 1, participants who saved passwords on IE were
not able to remember their actions correctly. Some of them even
claimed that they did not save passwords. We think this was an
important finding because it eliminated other explanations for
password saving. For instance, if participants had made a
deliberate choice, we could have speculated that participants
behaved so since they trusted other students using the same lab
or they thought that university environment is not as risky as an
Internet café, etc.
Our results also showed that almost all participants did not have
an idea about how to erase saved passwords. Even if they had
known, this would not have helped much since some
participants could not recall their choice of saving passwords in
the first place. Being conditioned to respond such pop-up boxes
quickly, participants’ responses to intrusive toolbars were
reflexive.
There may be concerns regarding ecological validity of
Experiment 1 since we instructed participants to finish tasks
(login to web pages) as fast as possible. It might be the case that
participants randomly clicked to an option on the active
(intrusive) communication to achieve the task demanded
quickly. In addition, it might be the case that participants did not
see the non-intrusive toolbar when using FF. We did not
explicitly explore whether participants did not save their
password because of not seeing the toolbar or not. Furthermore,
given that most of our participants were unfamiliar with
password autocomplete, they might have difficulties in
understanding questions about their memory. In Experiment 2,
these methodological problems were addressed.
4.2 Experiment 2
In Experiment 2, participants finished the task at their own pace
(we did not ask them to finish the tasks as soon as possible). To
measure the visibility of dialog box and toolbar used for
password autocomplete, we explicitly asked participants whether
Figure 5. Number of clicks made for each option as seen in Figure 1 and Figure 2 for password autocomplete on IE (left) and
FF (right) based on participants' memory in Experiment 1. (x-axis and y-axis represents click options and number of clicks
respectively.) (e.g., for IE, 12 users reported they clicked on "No", but 2 out of 12 actually saved their passwords.)
they had seen them during browsing. We also asked for the
confidence levels in their answers. We added the pictures of IE
dialog box and FF toolbar to the questionnaire and slightly
changed the wording of questions to clarify the meaning.
4.2.1 Method
Experiment 2 was conducted in the same laboratory. Procedure
was same as in Experiment 1 except the above mentioned
methodological differences. In order to conceal the true aim of
the study, participants were asked to check and confirm their
address information on the student registration page of Selcuk
University using IE and FF. The order of browser use was again
counterbalanced across participants. There were 30 participants
(10 of them were female, and mean age = 22.5), who were
students of Selcuk University. None of them participated in
Experiment 1.
4.2.2 Results
4.2.2.1 User Profile and User Knowledge on
Password Autocomplete
Approximately, half of the participants in Experiment 2 rated
their computer skills as average or below average (14
participants, 47%). Most of the participants of Experiment 2
were using Internet on daily basis (26 participants, 87%). About
half of them reported that they were using IE (14 participants,
47%), most of others were using either FF (6 participants, 20%)
or Google Chrome (7 participants, 23%). In Experiment 2, most
of the participants (23 participants, 85%) reported that they
knew about password autocomplete feature. Among these
participants almost all of them (21 out of 23 participants, 66%)
were using it for at least one account. 6 participants for both IE
and FF (25%) reported that they knew how to delete password
from browsers, but most of them could not correctly describe
how.
In summary, participants of Experiment 2 were non-expert
computer users. Most of them were actively using password
autocomplete unlike to the participants of Experiment 1.
However, similar to Experiment 1, most of the participants in
Experiment 2 did not know how to delete stored password on a
browser.
Figure 6. Number of participants who saved a
password on IE and FF in Experiment 2.
Figure 7. Number of different responses to the question “Did you
notice the dialog box / toolbar?" and “How confident are you?”
Figure 8. Number of clicks made for each option for password autocomplete on IE (left) and FF (right) based on
participants' memory in Experiment 2 (x-axis and y-axis represents click options and number of clicks, respectively).
4.2.2.2 Saving Passwords
In Experiment 2, 7 participants (23%) saved passwords on IE,
but only one participant (3.3%) saved password on FF (see
Figure 6). The association between browser type and saving
password was significant
2
(1)=4.97, p < 0.05]. These results,
which replicated results of Experiment 1, confirmed that
(intrusive) dialog box increases the tendency to save password
on a browser. Furthermore, these results could not be attributed
completely for the invisibility of FF's non-intrusive toolbar since
around half of participants (14 participants, 46%) reported that
they had seen FF's passive (non-intrusive) toolbar (see Figure 7).
Most of them were pretty sure about their answers.
In Experiment 2, among 7 participants who saved their password
on IE, half of them (3 participants, 43%) did not remember that
they clicked one of the options that saves the password. For FF,
one participant who saved password did not remember his/her
action correctly (see Figure 8).
4.2.3 Discussion
In Experiment 2, we replicated the result that active
communication increases the rate of saving password on a
browser. 7 participants out of 30 saved their passwords on a
public computer, when they were confronted with pop-up dialog
box. Contrarily, only one participant saved his/her password
with the non-intrusive toolbar. The significant association
between communication type and password saving behavior in
Experiment 2 confirmed our hypothesis with a different group of
participants. Furthermore, most of the participants in
Experiment 2 knew about and have been using password
autocomplete unlike to the participants of Experiment 1. The
similarity of results in Experiments 1 and 2 showed that saving
password with an active dialog box on a public computer is not
a direct consequence of unfamiliarity with password
autocomplete feature.
Although IE’s dialog box is more visible than FF’s toolbar, not
saving passwords in public computers is not a direct result of not
seeing the non-intrusive toolbar because half of our participants
in Experiment 2 reported that they remember seeing the toolbar
and most of them were very confident about their answers.
For participants who saved their passwords on lab computers, it
might be the case that they did so because they were unaware of
the risks of saving passwords on public computers. We tested
this assumption in Experiment 3.
4.3 Experiment 3
In Experiment 3 we investigated whether having knowledge on
password security has an effect on saving passwords on public
computers. In order to test this, we re-invited participants of
Experiment 1 for a new experiment. Participants of Experiment
1 were already given a lecture on password security and risks of
saving passwords on public computers. These participants would
be less likely to save passwords on a public computer if they had
saved it in Experiment 1 due to lack of knowledge on password
security. On the other hand, if participants’ responses to
intrusive dialog boxes had been reflexive, we would observe that
some participants save their password on IE in Experiment 3 as
well.
4.3.1 Method
The procedure of Experiment 3 was identical to Experiment 2.
There were twenty participants all of whom had participated in
Experiment 1. Experiment 3 was conducted about seven months
later than Experiments 1.
4.3.2 Results
4.3.2.1 Saving Passwords
In Experiment 3, 5 out of 20 participants (25%) saved their
password on IE, but none of them saved on FF (Figure 9). This
pattern of results revealed a significant relation between browser
type and saving password
2
(1)=5.71, p < 0.05], which
replicated Experiments 1 and 2. Similar to Experiment 2, about
half of the participants (9 participants, 45%) reported that they
had seen the toolbar of FF (Figure 10). Among the participants
who saved their password on IE, 2 of them remembered reported
that they did not save it (Figure 11).
4.3.3 Discussion
Experiment 3 replicated results of Experiment 2. We observed
that the tendency to save password with intrusive dialog box
exists among participants even if they had participated in the
same study previously and knew about the risks of saving
passwords on a public computer. About half of the participants
Figure 9. Number of participants who saved a
password on IE and FF in Experiment 3.
Figure 10. Number of responses to the question “Did you notice
the dialog box / toolbar?" and “How confident are you?”
reported that they had seen the nonintrusive toolbar of Firefox.
This result confirmed that nonintrusive toolbar is not completely
invisible.
5. GENERAL DISCUSSION
In this study we showed with repeated experiments that active
(intrusive) communication for password autocomplete increases
significantly the risk of inadvertent saving of passwords on
public computers (there is a significant association between
saving passwords on a public computer and type of
communication). Our last experiment also shows that some
participants saved their passwords with active type of
communication even if they were previously informed about the
security risks of saving passwords on public computers.
Furthermore, we observed that passive communication was not
completely invisible to the participants. In both Experiment 2
and Experiment 3 half of the participants reported that they had
seen the password autocomplete toolbar.
In our study we observed that among the participants who saved
their passwords, some of them remembered their choice
correctly while some did not. Surprisingly, this pattern of results
was observed even in Experiment 3 in which participants were
aware of the risks of saving passwords. It was interesting to
point out the numbers who self reported their savings
incorrectly. Not definite in any sense, but this data reminds how
tenuous it is to get self reported information.
In the lab experiments described above, we observed behavior of
users while they were using public computers. Another
important issue under our on-going investigation is the behavior
of users when they are using their own computers. We
performed a large survey study completed by 686 users to
understand the usage of password autocomplete feature in users’
own computers and the relationship between usage pattern and
the type of browser used. Due to space limitations, we cannot
discuss the results of this survey in detail in this paper. However
a snapshot of our results is provided in the Appendix for the
interested readers.
Based on our results, as a security recommendation we suggest
browser developers to choose passive communication for
password autocomplete. In this sense, we think it was a
considerate action to prefer passive communication in the latest
version of Internet Explorer (i.e., version 9) (We recommend a
similar change for password autocomplete in the Safari browser
which still uses dialog boxes in its latest version). However
since Internet Explorer version 9 is not compatible with
Windows XP, still the most popular version of Windows [20],
older versions of Internet Explorer are still widely used. Hence
average users might be more likely to continue saving their
passwords on public computers with Internet Explorer unless
another action (e.g., releasing an update for older versions of
Internet Explorer) is taken by Microsoft. We conjecture that our
results can be generalized to other security interactions in which
simply ignoring the communication does not pose any security
threat. This hypothesis may be of interest to test in a separate
study.
As an example, consider the dialog box in Internet
Explorer version 8 for warning about the content not secured
with SSL protocol (Figure 12). In our opinion, active
communication is not appropriate for this warning message
about mixed content, either. Providing only the secure content
without blocking user’s primary task and presenting the option
of viewing additional content not delivered with HTTPS in a
nonintrusive toolbar could be a better option
3
. Users are not
conditioned to react poorly to warnings and become more
effective to produce the appropriate behavior if active
3
Developers of Internet Explorer have not preferred passive
communication because they worry about the web layout problems
when only secure content is displayed [18].
Figure 12. Intrusive dialog for warning about the
content not delivered using secure connection in
Internet Explorer
version
8
.
Figure 11. Number of clicks made for each option for password autocomplete on IE (left) and FF (right) based on
participants' memory in Experiment 3 (x-axis and y-axis represents click options and number of clicks, respectively).
communication is used only when it is really needed.
6. CONCLUSION
Passwords are an easy target for attackers. In this paper, we
address an important aspect of password protection problem
previously untouched in the literature. We performed a number
of user studies which provide empirical evidence for the risks of
using intrusive dialog boxes to ask users input for password
autocomplete. In all three experiments we repeatedly observed
that participants may click on the “Yes” button reflexively and
store their passwords on a public computer when prompted with
a pop-up dialog box.
We suggest users to consult private browsing when they are
using public computers. With private browsing, password
autocomplete is disabled and no question is asked for user input.
This simple strategy prevents not only the problems due to
careless password savings but also mitigates privacy related
problems. We suggest secure interaction designers to think twice
before preferring an active communication over nonintrusive
alternatives. Unless active communication starts to be used less,
the market size would be increasing for commercial applications
such as PTFB (Push the Freaking Button) that automatically
responds to pop-up boxes on behalf of the user [6] [14].
7. ACKNOWLEDGEMENTS
We thank Paul C. van Oorschot and anonymous referees for
comments that considerably improved the paper. This research is
supported by TUBITAK (The Scientific and Technological
Research Council of Turkey) under project number 107E227.
8. REFERENCES
[1]
Browser Market Share,
http://marketshare.hitslink.com/report.aspx?qprid=0, last accessed
on 02/July/2011.
[2] L.F.Cranor: A framework for reasoning about the human in the
loop. In Proceedings of the 1st Conference on Usability,
Psychology, and Security, pages 1-15, Berkeley, CA, USA, 2008.
[3] R. Dhamija, J.D. Tygar, and M. Hearst. Why phishing works. In
Proc. of the SIGCHI Conference on Human Factors in Computing
Systems, pp. 581-590, New York, NY, USA, 2006, ACM.
[4] D. Florencio and C. Herley. A large-scale study of web password
habits. In Proc. of WWW (2007).
[5] S. Gaw, E.W. Felten, Password management strategies for online
accounts, in: SOUPS ’06, ACM Press, 2006, pp. 44–55.
[6] Peter Gutmann: Security usability,
http://www.cs.auckland.ac.nz/~pgut001/pubs/usability.pdf,
February 2008. Draft. Last accessed on 02/July/2011.
[7] E. Hayashi and J.I. Hong. A diary study of password usage in daily
life, In Proc. of CHI 2011.
[8] C. Heilman. Web Security: Are you part of the problem. White
paper,
http://coding.smashingmagazine.com/2010/01/14/web-
security-primer-are-you-part-of-the-problem/, last accessed on
02/July/2011.
[9] C. Herley, P.C. van Oorschot and A.S. Patrick. Passwords: If
We're So Smart Why Are We Still Using Them? Proc. Financial
Crypto 2009.
[10] R. Morris and K. Thompson. Password security: a case history.
Communications of the ACM, 22:594-597, 1979.
[11] C. Nodder: Users and trust: A microsoft case study. In L. F. Cranor
and S. Garfinkel, editors, Security and Usability: Designing Secure
Systems that People Can Use, August 2005.
[12] Kevin Purdy, post to lifehacker.com, Available at
http://lifehacker.com/5431466/autocomplete-extension-makes-
chrome-save-nearly-any-password, last accessed on 02/July/2011.
[13] Portable Firefox project, available at
http://portablefirefox.mozdev.org/, last accessed on 02/July/2011.
[14] PTFB Pro Mouse AutoClicker and Macro Recorder,
http://www.ptfbpro.com, last accessed on 02/July/2011.
[15] B.Ross: Firefox and the worry free web. In L.F. Cranor and
S.Garfinkel, editors, Security and Usability: Designing Secure
Systems that People Can Use, August 2005.
[16] Brent Strange, Password harvesting with AutoComplete, available
at
http://www.testingreflections.com/node/view/3482, last
accessed on 02/July/2011.
[17] Usage share of web browsers,
http://en.wikipedia.org/wiki/Usage_share_of_web_browsers
[18] Walker News, Why IE8 Displays Security Warning When Loading
HTTPS Page?,
http://www.walkernews.net/2009/10/19/why-ie8-
displays-security-warning-when-loading-https-page/.
[19] Alma Whitten and J. D. Tygar. Why Johnny can’t encrypt: A
usability evaluation of PGP 5.0. In 8th USENIX Security
Symposium, pages 169 – 184. Usenix, 1999.
[20] Windows XP, http://en.wikipedia.org/wiki/Windows_XP
APPENDIX: Survey Study
Methodology and Results
With the aim of collecting information for the use of password
autocomplete in participants’ own computers, we conducted an
online web-based survey in June 2011 (three months after
version 9 of Internet Explorer is made publicly available) with
students and employees of TOBB University of Economics and
Technology. There were 686 participants in total (242 of them
were female, and mean age = 22.68). They gave subjective
ratings about their knowledge on computers on a Likert scale (1-
5). The average rating was 3.73 (with standard deviation of
0.82). Majority of our participants rated themselves as average,
and above-average computer users. Among 686 participants 305
of them (44.5%) were using Google Chrome (GC), 37 of them
(5.4%) were using Firefox (FF) 3.x or a lower version, 237 of
them (34.5%) were using FF 4.x, 49 of them (7.1%) were using
Internet Explorer (IE) 8.x or a lower version, 39 of them (5.7%)
were using IE 9.x, 7 participants (1.0%) were using Safari, and
remaining 12 participants (1.7%) were using other browsers.
GC, FF and IE 9.x have non-intrusive toolbars for the password
autocomplete feature whereas IE 8.x (and lower versions) and
Safari implement intrusive dialog boxes. On their own
computers, majority of our participants (630, 91.8%) were using
browsers implementing password autocomplete with
nonintrusive type of communication. We divide participants into
two groups (non-intrusive vs. intrusive) and in the following
analysis we compare these two groups with respect to the
Figure 13. Usage share of browsers in the survey study
information they reported about password autocomplete.
We asked our participants whether they knew about the
password autocomplete feature. We compared the proportion of
participants who reported knowing it with respect to the group
they belong to. While 87% (548 of 630) of users in the non-
intrusive group reported that they knew about the feature, this
proportion drops to 77% (42 of 56) for the other group, which
was a statistically significant difference [χ
2
(1)=4.48, p<0.05]
(see Figure 14).
We asked participants the ratio of their passwords saved on
browser with the password autocomplete feature. Based on the
information reported, 106 participants (15%) saved none of their
passwords on browser. 191 (27%) reported that they saved up to
25% of their passwords. 160 of them (23%) saved 25-75% of
their passwords, and 229 (33%) saved 75-100% of their
passwords. We observed significant differences between the
groups of non-intrusive and intrusive [χ
2
(3)=10, p<0.05] (see
Figure 15). Significantly more users (35%, 219 of 630) in the
nonintrusive group save majority (i.e., 76-100%) of their
passwords. On the other hand, significantly more participants
(39%, 22 of 56) in the intrusive group save only 1-25% of their
passwords with the password autocomplete feature.
Discussion
In the lab studies, we have shown that active communication for
password autocomplete brings security risks when public
computers are in use. An additional important finding obtained
in the survey study is that with active dialog boxes the ratio of
passwords saved on users’ own computers is less than the
passwords saved with the passive toolbar. Similarly,
significantly a smaller proportion of participants in the intrusive
group reported that they knew about password autocomplete
feature as compared to non-intrusive group. With the
assumption that knowing password autocomplete and ratio of
passwords saved are indicators of usability of the
implementation of password autocomplete feature, we can say
that passive communication does not have any usability
disadvantage in the environment of users’ own computers (due
to its less visibility or for other reasons). This result confirms
our conclusion that active communication for password
autocomplete should be avoided in web browsers.
In the survey study usage share of browsers is substantially
different than the share in our lab studies (i.e., IE is the most
popular browser among the participants of lab study in contrast
to the survey study). We note that user bases are different in
these two studies. In addition, this difference may be partially
attributed to the rise of new browsers.
It is interesting to note that in the survey study more than half of
IE users still reported that they did not use the latest version
(version 9) three months after its release. On the other hand,
older versions were reported to be less used among Firefox
users.
Figure 14. Proportion of participants who knew about
password autocomplete feature as a function of
communication type implemented in their browsers.
Figure 15. Proportion of participants as a function of
ratio of passwords saved on their browsers in intrusive
and nonintrusive groups.
... Using insights from the initial study we improve the Tapas design and then conduct a 10 participant follow-up study to evaluate it, finding it improves user's understanding of the system. 1 Tap-based authentication using a smartphone ...
... Chiasson et al. [7] examined two password managers, finding significant usability and security failings related to entry of the master password as well as inaccurate/incomplete mental models of the software. Bicakci et al. [1] examined the user interface of browser-based managers and the tendency of users to inadvertantly save private information on a public computer. ...
... Participants in the NMP condition (no setup required) were also allowed to enter comments regarding setup. A few voiced concerns about the simplicity of setup, stating that it was almost "too simple", and that you may actually end up accidentally saving passwords with the manager you didn't intend to save, a concern echoed in the literature [1]. Comments like these reinforce the Tapas design feature that requires signalled intent on both devices prior to saving account information or logging in using the password manager. ...
Article
Passwords continue to prevail on the web as the primary method for user authentication despite their well-known se-curity and usability drawbacks. Password managers offer some improvement without requiring server-side changes. In this paper, we evaluate the security of dual-possession au-thentication, an authentication approach offering encrypted storage of passwords and theft-resistance without the use of a master password. We further introduce Tapas, a concrete implementation of dual-possession authentication leveraging a desktop computer and a smartphone. Tapas requires no server-side changes to websites, no master password, and protects all the stored passwords in the event either the primary or secondary device (e.g., computer or phone) is stolen. To evaluate the viability of Tapas as an alternative to traditional password managers, we perform a 30 partic-ipant user study comparing Tapas to two configurations of Firefox's built-in password manager. We found users signif-icantly preferred Tapas. We then improve Tapas by incorpo-rating feedback from this study, and reevaluate it with an additional 10 participants.
... In contrast, other researchers show that people's privacy decisions are not always so rational ( Grossklags 2005, 2008), and that computer users often avoid the hassle of exploiting the control given to them (Compañó and Lusoli 2010). Moreover, an abundance of control can cause significant inconvenience: filling out web forms for instance is seen as a typical nuisance (Bicakci et al. 2011; Trewin 2006). All modern browsers therefore offer some sort of auto-completion feature for web forms, and web designers are encouraged to make forms that use this feature (Garrido et al. 2011; Wroblewski 2008). ...
... Giving people control over their information disclosure decisions has several downsides and shortcomings though (Brandimarte et al. 2013 To reduce the burden of information disclosure, modern Internet browsers have a form auto-completion feature, known as " AutoComplete " 3 , " AutoFill " 4,5 , or " Auto Form Fill " 6 . Auto-completion tools reduce the required amount of typing, and help users to recall the correct information (Bicakci et al. 2011; Trewin 2006). Usability experts therefore recommend to web developers to build their forms in a way that enables them to be recognized by these auto-completion aids (Garrido et al. 2011 Despite the apparent benefits of auto-completion, Preibusch et al. (2012) warn that since these tools typically fill all the fields on a form (even optional fields), they could increase the risk of over-disclosure. ...
Conference Paper
Full-text available
When filling out web forms, people typically do not want to submit every piece of requested information to every website. Instead, they selectively disclose information after weighing the potential benefits and risks of disclosure: a process called "privacy calculus". Giving users control over what to enter is a prerequisite for this selective disclosure behavior. Exercising this control by manually filling out a form is a burden though. Modern browsers therefore offer an auto-completion feature that automatically fills out forms with previously stored values. This feature is convenient, but it makes it so easy to submit a fully completed form that users seem to skip the privacy calculus altogether. In an experiment we compare this traditional auto-completion tool with two alternative tools that give users more control than the traditional tool. While users of the traditional tool indeed forego their selective disclosure behavior, the alternative tools effectively reinstate the privacy calculus.
... A potential workaround for the privacy policies could be to analyze the text-based privacy policies using deep learning [115]. For the settings, an "overlay" can be developed that automatically fills out the privacy settings as soon as the user accesses the settings page, much like a form auto-completion tool [34,366]. ...
Technical Report
Full-text available
The purpose of this document is to make recommendations for implementing User-Tailored Privacy (UTP) into Total Learning Architecture (TLA)-based systems and to inform ADL and other TLA performers about the Modeling Factors that need to be considered in the context of this implementation. The set of recommendations put forth in this document will allow ADL and other TLA performers to build a user-tailored privacy decision-support system that supports users in making better privacy decisions.
Chapter
Federated Identity Management (FIdM) stellt einen Ansatz zum Austausch vertraulicher Ressourcen zwischen verschiedenen Parteien in ungleichen Umgebungen dar. Solche Umgebungen sind z. B. dann gegeben, wenn über Unternehmensgrenzen mit Benutzerinformationen hinweg gehandelt werden muss. Die Anwendungsszenarien sind dabei vielfältig und reichen von kleinen Service-Anbietern im Internet, bis hin zu unternehmenskritischen Geschäftsbereichen in weltweit agierenden Unternehmen. Eine wichtige Eigenschaft in diesem Zusammenhang ist die des sogenannten Single Sign-On (SSO), bei dem der Benutzer in die Lage versetzt wird, mit mehreren Diensten zu agieren, sich jedoch nur ein einziges Mal zu Beginn authentifizieren muss. Föderations-Technologien erfüllen hierbei im Wesentlichen zwei wichtige Aufgaben: 1. Service-Provider sind in der Lage, Benutzer, die durch eine andere Partei, den Identity-Provider, authentifiziert wurden, auf sichere und standardisierte Art und Weise zu identifizieren [S08]. 2. Identitäts-Föderationen erlauben eine Delegation von Identitätsaufgaben zwischen bzw. über verschiedene Sicherheitsdomänen hinweg [MR08]. Balasubramaniam et al. identifizierte folgende funktionalen Anforderungen, die ein Identitätsmanagement zu erfüllen hat: Bereitstellung von Identitäten (Provisioning), Authentifizierung und Autorisierung, Speicherverwaltung, Indexierung von Identitätsinformationen, Zertifizierung von Identitäten sowie Credentials, Single Sign-On/single Sign-Off sowie Auditierung [BLM + 09]. Weiterhin muss ein Identitätsmanagement dafür Sorge tragen, dass Identitäten zum richtigen Zeitpunkt dem richtigen Service verfügbar gemacht werden. Ein weiterer wichtiger Aspekt wird vor allem in letzter Zeit immer dringlicher, da Fälle von Identitätsdiebstahl und den damit zusammenhängenden Missbrauch in den letzten Jahren kontinuierlich zugenommen haben. Aus diesem Grund muss es auch die Aufgabe eines guten Identitätsmanagementsystems sein, sich mit diesem Problem auseinanderzusetzten und für ein hohes Maß an Sicherheit und Datenschutz zu sorgen. Neben diesen funktionalen sowie sicherheits- und datenschutzrelevanten Aspekten gehört die Benutzbarkeit sicherlich zu den großen Herausforderungen, die es beim Konzipieren eines solchen Systems zu meistern gilt. Gelingt es, die Balance dieser drei Bereiche ideal aufeinander abzustimmen, so ist man dem Ziel sicherlich einen Schritt näher gekommen, ein perfektes Identitätsmanagementsystem zu entwerfen. Auf dem Markt existieren inzwischen etliche Lösungen, die sowohl kommerzieller Natur sind als auch als Open Source Varianten vorliegen. All diese Produkte unterscheiden sich bezüglich der drei erwähnten Aspekte, richten jedoch ihren Fokus auch auf unterschiedlichste Gegebenheiten, Zielgruppen und Voraussetzungen aus.
Purpose – Phishing is essentially a social engineering crime on the Web, whose rampant occurrences and technique advancements are posing big challenges for researchers in both academia and the industry. The purpose of this study is to examine the available phishing literatures and phishing countermeasures, to determine how research has evolved and advanced in terms of quantity, content and publication outlets. In addition to that, this paper aims to identify the important trends in phishing and its countermeasures and provides a view of the research gap that is still prevailing in this field of study. Design/methodology/approach – This paper is a comprehensive literature review prepared after analysing 16 doctoral theses and 358 papers in this field of research. The papers were analyzed based on their research focus, empirical basis on phishing and proposed countermeasures. Findings – The findings reveal that the current anti‐phishing approaches that have seen significant deployments over the internet can be classified into eight categories. Also, the different approaches proposed so far are all preventive in nature. A Phisher will mainly target the innocent consumers who happen to be the weakest link in the security chain and it was found through various usability studies that neither server‐side security indicators nor client‐side toolbars and warnings are successful in preventing vulnerable users from being deceived. Originality/value – Educating the internet users about phishing, as well as the implementation and proper application of anti‐phishing measures, are critical steps in protecting the identities of online consumers against phishing attacks. Further research is required to evaluate the effectiveness of the available countermeasures against fresh phishing attacks. Also there is the need to find out the factors which influence internet user's ability to correctly identify phishing websites.
Conference Paper
Full-text available
While a lot has changed in Internet security in the last 10 years, a lot has stayed the same - such as the use of alphanumeric passwords. Passwords remain the dominant means of authentication on the Internet, even in the face of significant problems related to password forgetting and theft. In fact, despite large numbers of proposed alternatives, we must remember more passwords than ever before. Why is this? Will alphanumeric passwords still be ubiquitous in 2019, or will adoption of alternative proposals be commonplace? What must happen in order to move beyond passwords? This note pursues these questions, following a panel discussion at Financial Cryptography and Data Security 2009.
Article
Full-text available
In the security community, we’ve always recognized that our security proposals come with certain costs in terms of usability. Traditionally, that’s the compromise we make to get security. But the market has ruled against us. Time and time again, our fielded secure systems are ignored, bypassed, turned off, or constrained to such a small part of the process that the security result is practically nonexistent. Even worse for our mental self-satisfaction, those systems that claim to deliver security to users simply don’t pass muster--they’re not what we’d like to think of as secure systems.
Conference Paper
To build systems shielding users from fraudulent (or phishing) websites, designers need to know which attack strategies work and why. This paper provides the first empirical evidence about which malicious strategies are successful at deceiving general users. We first analyzed a large set of captured phishing attacks and developed a set of hypotheses about why these strategies might work. We then assessed these hypotheses with a usability study in which 22 participants were shown 20 web sites and asked to determine which ones were fraudulent. We found that 23% of the participants did not look at browser-based cues such as the address bar, status bar and the security indicators, leading to incorrect choices 40% of the time. We also found that some visual deception attacks can fool even the most sophisticated users. These results illustrate that standard security indicators are not effective for a substantial fraction of users, and suggest that alternative approaches are needed.
Conference Paper
While past work has examined password usage on a specific computer, web site, or organization, there is little work examining overall password usage in daily life. Through a diary study, we examine all usage of passwords, and offer some new findings based on quantitative analyses regarding how often people log in, where they log in, and how frequently people use foreign computers. Our analysis also confirms or updates existing statistics about password usage patterns. We also discuss some implications for design as well as security education.
Conference Paper
Given the widespread use of password authentication in on- line correspondence, subscription services, and shopping, there is growing concern about identity theft. When peo- ple reuse their passwords across multiple accounts, they in- crease their vulnerability; compromising one password can help an attacker take over several accounts. Our study of 49 undergraduates quantifles how many passwords they had and how often they reused these passwords. The majority of users had three or fewer passwords and passwords were reused twice. Furthermore, over time, password reuse rates increased because people accumulated more accounts but did not create more passwords. Users justifled their habits. While they wanted to protect flnancial data and personal communication, reusing passwords made passwords easier to manage. Users visualized threats from human attackers, particularly viewing those close to them as the most moti- vated and able attackers; however, participants did not sep- arate the human attackers from their potentially automated tools. They sometimes failed to realize that personalized passwords such as phone numbers can be cracked given a large enough dictionary and enough tries. We discuss how current systems support poor password practices. We also present potential changes in website authentication systems and password managers.
Conference Paper
We report the results of a large scale study of password use and password re-use habits. The study involved half a mil- lion users over a three month period. A client component on users' machines recorded a variety of password strength, usage and frequency metrics. This allows us to measure or estimate such quantities as the average number of pass- words and average number of accounts each user has, how many passwords she types per day, how often passwords are shared among sites, and how often they are forgotten. We get extremely detailed data on password strength, the types and lengths of passwords chosen, and how they vary by site. The data is the flrst large scale study of its kind, and yields numerous other insights into the r^ole the passwords play in users' online experience.
Conference Paper
Many secure systems rely on a "human in the loop" to perform security-critical functions. However, humans often fail in their security roles. Whenever possible, secure system designers should find ways of keeping humans out of the loop. However, there are some tasks for which feasible or cost effective alternatives to humans are not available. In these cases secure system designers should engineer their systems to support the humans in the loop and maximize their chances of performing their security- critical functions successfully. We propose a framework for reasoning about the human in the loop that provides a systematic approach to identifying potential causes for human failure. This framework can be used by system designers to identify problem areas before a system is built and proactively address deficiencies. System operators can also use this framework to analyze the root cause of security failures that have been attributed to "human error." We provide examples to illustrate the applicability of this framework to a variety of secure systems design problems, including anti-phishing warnings and password policies. "Humans are incapable of securely storing high-quality cryptographic keys, and they have unacceptable speed and accuracy when performing cryptographic operations. (They are also large, expensive to maintain, difficult to manage, and they pollute the environment. It is astonishing that these devices continue to be manufactured and deployed. But they are sufficiently pervasive that we must design our protocols around their limitations.)" -- C. Kaufman, R. Perlman, and M. Speciner, 2002 (20)
Article
User errors cause or contribute to most computer security failures, yet user interfaces for security still tend to be clumsy, confusing, or near-nonexistent. Is this simply due to a failure to apply standard user interface design techniques to security? We argue that, on the contrary, effective security requires a different usability standard, and that it will not be achieved through the user interface design techniques appropriate to other types of consumer software. To test this hypothesis, we performed a case study of a security program which does have a good user interface by general standards: PGP 5.0. Our case study used a cognitive walkthrough analysis together with a laboratory user test to evaluate whether PGP 5.0 can be successfully used by cryptography novices to achieve effective electronic mail security. The analysis found a number of user interface design flaws that may contribute to security failures, and the user test demonstrated that when our test participants were g...
Article
This paper describes the history of the design of the password security scheme on a remotely accessed time-sharing system. The present design was the result of countering observed attempts to penetrate the system. The result is a compromise between extreme security and ease of use.