pfn / keepasshttp

KeePass plugin to expose password entries securely (256bit AES/CBC) over HTTP
GNU General Public License v3.0
1.99k stars 275 forks source link

CBC mode is malleable #94

Open ott opened 11 years ago

ott commented 11 years ago

KeePassHttp uses AES in CBC mode, which is malleable. The nonce based authentication doesn't prevent this either (if it is supposed to be a MAC, it is badly broken). Using AES in GCM mode prevents the respective attacks, makes the nonce based authentication unnecessary and can be easily added.

I'm not sure what the attack scenarios for KeePassHttp are (when used with PassIFox, it seems cryptography is only used to prevent other local users from accessing KeePassHttp which makes encryption unnecessary), but if encryption is used to protected against active attacks over the network, it definitely doesn't fulfil this purpose.

I can provide a patch if backwards compatibility is not an issue.

pfn commented 11 years ago

Backward compatibility is an issue, and the encryption is meant to protect against active attacks outside of the initial pairing.

Please describe an attack vector (specific to the protocol as implemented) that can compromise the current scheme.

Sent from my phone On Mar 25, 2013 9:37 AM, "Matthias-Christian Ott" notifications@github.com wrote:

KeePassHttp uses AES in CBC mode, which is malleable. The nonce based authentication doesn't prevent this either (if it is supposed to be a MAC, it is badly broken). Using AES in GCM mode prevents the respective attacks, makes the nonce based authentication unnecessary and can be easily added.

I'm not sure what the attack scenarios for KeePassHttp are (when used with PassIFox, it seems cryptography is only used to prevent other local users from accessing KeePassHttp which makes encryption unnecessary), but if encryption is used to protected against active attacks over the network, it definitely doesn't fulfil this purpose.

I can provide a patch if backwards compatibility is not an issue.

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/94 .

ott commented 11 years ago

Can you describe a scenario where a passive attack on the loopback network is possible but an active attack is not (except for the initial pairing which of course makes an FCFS attack by a local attacker against the password database possible)?

pfn commented 11 years ago

None that I am currently aware of

Sent from my tablet On Mar 25, 2013 10:06 AM, "Matthias-Christian Ott" notifications@github.com wrote:

Can you describe a scenario where a passive attack on the loopback network is possible but an active attack is not (except for the initial pairing which of course makes an FCFS attack by a local attacker against the password database possible)?

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/94#issuecomment-15406363 .

ott commented 11 years ago

I think an active attacker can use to truncate or change passwords in the set-login handler.

pfn commented 11 years ago

That is a very good example of where an unauthenticated message fails. Thanks for pointing that out, I'll consider how to fix this in the future (whether it be by using a ccm mode, or whatnot).

On Mon, Mar 25, 2013 at 10:31 AM, Matthias-Christian Ott < notifications@github.com> wrote:

I think an active attacker can use to truncate or change passwords in the set-login handler.

— Reply to this email directly or view it on GitHubhttps://github.com/pfn/keepasshttp/issues/94#issuecomment-15408032 .