Re: criticism of web based password manager requested

From: Ben Livengood (
Date: 06/09/05

Date: 8 Jun 2005 19:27:23 -0700

> I'm not sure what version issues you're referring to ... it's the
> latest version.. if it's changed by someone else then it's either not
> going to work (different encryption key (obvious because you can't
> decrypt it) or different data (can't log in with it)) or it's going to
> work just fine.... ignoring the fact that your data has been
> compromised versioning doesn't enter into it really.

What about an active snooping attacker (including an untrusted server)
who sees you access your bank account password, then when you request
another password to a system which the attacker owns, sends you the
data for your bank account again? There's a probability that you'll
paste your bank password into the attackers login system, giving him
full access to your money. Note that with AES-CBC and the same key, it
is possible to splice different data streams together (say, two
different password entries) and the result will decrypt fine except for
one garbage block. This attack might be difficult to detect if you
store any padding in the entries and don't use message authentication.
Using message authentication and encrypting each user's password
database as a whole would thwart this attack.

> I'm worried about the security of MY install of it. Not if it's safe on
> someone elses box because i know i can't trust another box unless i can
> see the code.. and that's part of the point here.. i (or anyone esle)
> can always check the js to see what it's doing before trusting the
> server. With the correct js in place i don't have to trust ANYTHING
> about the server it's submitting to

That is true so long as you can compare it exactly with what you
originally wrote. Something as simple as changing = to == in the md5 or
aes code could theoretically cause your password to be sent to an
attacker in plaintext or an easily reversable form. My point was that
if you rely on an untrusted server to obtain the javascript that you
run locally, you must have an independant way of verifying it exactly,
and you must do it each time you download the javascript. An attack
that only sent the modified javascript every 16th connection would
still recover most users' passwords, because most users would not check
the javascript each time.

> ssl http authentication would be compromised if the server was hacked
> into which is an all to frequent problem. This is a multi user system
> so i can't encrypt the whole db

Each user's list of passwords could be encrypted in a single database.

>>From original post:
> When a user loads data they are given the start and length points but
> the verification hash is never passed out.
> When adding/updating data they have to generate and pass in a hash for
> any previously saved login which the server matches against what it
> has. If they're updating a login they of course need to also pass in
> new start and length points and new value for checking against next
> time.

Eavesdroppers can authenticate at will, and also change the new
authentication hash without knowing the password. All they have to know
is the previously sent hash which is sent in the clear, and generate a
random hash. By choosing a random length from the username and password
catenation, the hash is also weakened significantly, since the hash of
a 1 or 2 byte string would be easy to brute force, and would be
generated by the client eventually. Also, because of the birthday
paradox, only 256 password changes would result in a 50% chance of
authentication hash reuse, which would increase from there.

Proper authentication requires either public key cryptography or a
shared secret with the server. You can generate a secret key to use as
an http password or in a direct challenge response authentication with
the server, or you can generate a public and private key on the client,
encrypt the private key with the passphrase, and send both to the
server as part of creating a new user account. Then to log in, request
the encrypted private key, decrypt it with the passphrase and use it to
sign messages to the server. If you want to use just a secret key, just
take a hash of the hash of the passphrase and use that. You will need
SSL to create a new user, since you will need to transmit the secret
key to the server securely. To authenticate you, the server should send
a random challenge, you catenate the secret key to the challenge, hash
the result, and send it to the server which can generate the same hash
since it knows your secret key. The server always has to use a new
challenge, and it should be at least as long as the hash size. Public
key authentication doesn't require SSL, and can run entirely on the
client except for signature verification on the server which only
requires knowledge of the public key.

> but asside from the standard issues of security on the web do you see
> any holes in the mechanism itself?

So long as AES is used properly (e.g. not just ECB, use random IVs for
each message), and you use secure passphrases with enough entropy to
resist dictionary attacks, the data itself should be secure. The
authentication mechanism needs work if the data needs to be protected
from deletion by third party attackers (e.g. attackers not on the
server or the client).