![](bg4.png)
We answer the second question “what is code cor-
ruption?” gradually. We start with a very general
and powerful definition, but we will later constrain
it while answering the last question “what levels of
corruption are reasonable to consider”?
Definition 2. Let ls.exe be the code that defines the
protocol executed by the LS. Code corruption of LS
means changing ls.exe.
With its code corrupted, the LS’s working can
change completely. An intruder can reprogram it to
do whatever, e.g., to play chess.
1
However, we are
not interested in attacks that change the functionality
of the LS, for the reason that they do not help the ad-
versary to increase its probability of successful log-
ging in. For a similar reason, we are not interested in
attacks that shut-down the systems or cause Denial-
of-Service. These are important attacks from which
to seek defense, but out-of-scope in this study.
We also exclude attacks such as those consisting
in changing ls.exe to always grant access. Actually,
there is a technical reason for this choice. The origi-
nal paper does not give full detail of the architecture
of the “computer system”, our LS, but it seems reaso-
nable to assume that Honeywords System implements
a separation of duties (Botha and Eloff, 2001). And
the duty of LS is only to search the proffered pass-
word in the password file, to consult the HC, and pos-
sibly to report the decision to the user, but not to grant
or deny accesses.
So, what is a reasonable code corruption? We con-
sider here a particular type of corruption, as much as
possible “undetectable”, that is working without rai-
sing suspect of LS’s misbehaving into the other modu-
les. This can be achieved by changing ls.exe in such
a way that LS’s behaviour remains the same from the
point of view of the modules it interacts with, mainly
from the viewpoint of who can raise alarms, primarily
the HC and, secondarily, the system administrators.
Assumption 2. A code corruption against LS does
not change the LS’s observable behaviour.
The rationale of this assumption is that, if the ad-
versary changes the observable behaviour of LS, this
would result in an anomaly that can be detected, trig-
gering an alert in response to which a safe version of
the ls.exe can be restored. Since the adversary may
have a once-in-lifetime opportunity to corrupt LS’s
code, he may not want to see his efforts vanishing in
this way. Of course not all attackers will be so concer-
ned about being undetected. They can be satisfied by
managing to log in and say ex-filtrate sensitive data
1
This is what R. Gonggrijp did when, in 2006, proved
insecure a Dutch electronic voting machine.
might be fine, even if this leaves a trail. But we de-
cided to scope our analysis only within the context of
Assumption 2.
However, even under Assumption 2 there are sub-
tleties that need to be addressed. Interpreted strictly it
does not allow the creation of any back door between
the adversary and the LS that this last can use at any-
time to leak information. This is because, interpre-
ting strictly the term “undetectability”, an exchange
of messages from the LS towards the adversary and
outside the protocol’s message flow can be eventu-
ally detected (e.g., by monitoring the net traffic), lea-
ding to have a safe version of the ls.exe re-installed.
Thus according to this interpretation, Assumption 2
says that if the intruder wants to communicate with
the corrupted LS, it must use the same channels from
which legitimate users log in, and must respect the
message flow of the honest protocol. This does not
exclude that, when re-coding ls.exe, the adversary
can use the knowledge he has gained from having hac-
ked the password file in the first place. It can use the
user’s IDs and sweetwords, and it can hard-code this
information in the corrupted ls.exe.
Still, if we take Assumption 2 less strictly, it ad-
mits that some information can flow back to the ad-
versary, for example, in message resp. And, as we
will discuss in detail in §4, letting LS to communicate
back to the adversary leads to a powerful attack that
breaks the original Honeywords System. In short, the
attack works because LS can learn u’s password (or
the hash of it). This is a feature more than a vulnera-
bility but a feature that a collusive adversary able to
invert the hash can exploit to know the password. So,
an incentive for code corrupting the LS is exactly to
create this retroactive communication and we cannot
exclude this possibility in our analysis. We propose
thus the following methodology. By default we inter-
pret Assumption 2 strictly but, separately, we always
discuss what happens if we relax this constraint and
let LS leak information to the intruder.
Notably, the new protocol that we describe in §5,
although designed to secure the Honeywords System
under an Assumption 2 interpreted strictly turns out to
be efficient also when we relax it. The new protocol
will not impede the leak nor stop the adversary from
learning u’s password, but will make that information
useless for the adversary because it will not be able
log in with it into the system. Somehow our solution
reduces considerably the role of the password as the
only authentication token.
ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy
86