Open ott opened 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 .
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)?
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 .
I think an active attacker can use to truncate or change passwords in the set-login handler.
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 .
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.