We now turn to the design of the full honey-vault service that we call NoCrack.
Our architecture closely follows deployed commercial systems, such as LastPass6. A web-storage service exposes a RESTful web API over HTTPS for backing up user
vaults and synchronizing vaults across devices. To achieve the security benefits of
HE, however, we must design this service carefully.
The challenge of password-based logins. One encounters an interesting chal-
lenge when attempting to build a decoy-based system which supports backup of
user vaults: how to authenticate users to the service that is responsible for backing
up their vaults. In particular, the status quo in industry is for users to choose a
username and service password. The password would be sent over HTTPS to the
server, hashed, and stored to authenticate future requests. But customers are likely
to choose this service password to be the same as their vault’s master password. If
an attacker compromises the storage service and obtains both a user’s encrypted
vault and the service password hash, they can mount a brute-force attack against
the service password hash, learn the service password, and then decrypt the vault.
One might attempt to mitigate with this by securing the password hash sepa-
rately from vaults. Or one could avoid backup of encrypted vaults entirely, but this
would leave users responsible and violate our goal of matching features of existing
services. We therefore go a different route, and forego password-based login to the
storage service completely.
Device enrollment. A new user registers with the service by providing an email
address (also used as an identifier), to which a standard proof-of-ownership chal-
lenge is sent. To hinder abuse of the registration functionality, the service can rate
limit such requests and require solution of an appropriate CAPTCHA [52]. The
proof-of-ownership is an email including a randomly generated 128-bit temporary
token (encoded in Base64 format, 22 characters long). The user copies this tem-
call. The server verifies the temporary token, and returns to the client program a
(long term) bearer token (also 128 bits) that can be used as a key to authenticate
subsequent requests using HMAC. At this stage the client device is enrolled. Note
that all communication is performed over TLS.
Additional devices can be enrolled in a similar manner by having an already-
enrolled client device to generate a token for the new device or sending a new
temporary token via email. Should a user lose all access to a device with a current
bearer token, they can easily obtain a new token via the same enrollment process.
We note that two-factor authentication would be straightforward to support
by requiring a proof-of-ownership of a phone number or a correct hardware token-
generated one-time password to obtain a device bearer token.
Synchronizing with the server. An enrolled client device can compare their
local information with that stored under their account on the server. This involves
ensuring the client and storage service have the same version of the vault, which,
in normal usage, is cached on the client device. To save bandwidth, downloads and
uploads can be done in an efficient manner via any standard “diff” mechanism —
in particular our HE schemes support sending only portions of the ciphertext at a
time.
The client. We currently have only a command line client supported, but future
versions could easily integrate with popular browsers via an extension. The client
caches the vault locally, but never stores it in the clear on persistent storage. The
client queries the service when run to determine if it needs to synchronize the
vault. At the beginning of a browsing session, the user is prompted for the master
security skins [53] (as suggested also for use with Kamouflage), which show a color
or picture that is computed as a hash of the master password (but never stored).
The output of the KDF can be cached in memory in order to decrypt individual
domains as needed, while the master password itself is expunged from memory
immediately.
Note that the HE scheme does not handle login names; we assume that browser
caching mechanisms can handle this for a user if they desire. Should a login
detectably fail for the user due to master password typo and the user does not
observe the incorrect security skin, the client can prompt the user to reenter their
master password. By construction, there might be dummy password entries in
NoCrack for some domains where the user does not have an account. The user
and/or the browser is responsible to distinguish the domains where the user has
an account.
Implementation and performance. We implemented a prototype of NoCrack
in Python-2.7. On the server side we used Flask and Sqlite3. To normalize do-
mains we use the Python Public-Suffix library. All cryptographic operations use
PyCrypto-2.6.1. We use AES within CTR mode encryption, and SHA-256 within
PBKDF2 for key derivation. Many of the operations are parallelizable; we use the
Python multiprocessing library for this but note that our prototype implementa-
tion does not yet fully take advantage of parallelization. The client and server
consist of 3,102 total lines of code as counted by the utility cloc (not counting li-
braries). All experiments were performed on an Intel Core-i5 with 16 GB of RAM
running Linux.
We provide some basic performance numbers for our most complex honey
Operation s= 2 200 2,000 20,000
Recover password 6.34 ms 6.41 ms 6.42 ms 6.50 ms
Add password 0.13 s 0.68 s 1.11 s 9.25 s
Vault size on disk 4.71 KB 164.00 KB 1.55 MB 15.26 MB
Figure 2.7: Running times (median over 100 trials) of operations for different vault sizes s= s1+ s2. The final row is size of encrypted vaults on disk.
tion and some improvements will be easy. We fix various vault sizes s ∈
{2 , 200 , 2,000 , 20,000} and set s1 = s2 = s/2 (these are the sizes of the popular domains table and overflow table, respectively). We used integer representation
size b= 128. for encoding fractions. We start by generating a random ciphertext of size appropriate for the values of s1, s2 assuming some short arbitrary domain
size and that all passwords are human generated (the worst-case for performance).
We then measure the time to recover a particular vault password as well as to add
a password to the vault. We report in Table2.7 the median times over 100 trials. Variance in timing was negligible.
Time for recovering a single password is fast, and agnostic to the size of the
vault. This is because our design allows random access into the vault. Time for
adding passwords increases with s, since our scheme decrypts and decodes all s
entries, updates the new password, then re-encodes and re-encrypts all s entries
(this is required to keep the sub-grammar synchronized with the contents of the
vault.) The bulk of the time is spent in encoding and re-encoding passwords.
This operation is still only around one second for large vaults, and large vaults are
needed only to support domain hiding. The encrypted vaults are also of reasonable
size. We conclude that, while NoCrack does incur time and space overheads relative
to conventionally encrypted vaults, the absolute performance is more than sufficient