Hi, On 4 March 2015 at 15:22, Stephen Frost <sfr...@snowman.net> wrote: > That really just changes it back to the 'password' case though, doesn't > it? An attacker who can sniff the network would get the response from > the client and be able to use it in a replay attack just as if it was > the password.
They can already do that if they reconnect 65k times (on average - this could be fixed by choosing the challenges sequentially instead of randomly). But yes, the intent is to make it as secure as the 'password' case. > Sure, we could store multiple responses, but given that we don't have > any auto-lockout mechanism after X bad attempts or anything like that, > an attacker could simply continue retrying until we pick the one which > they sniffed. You'd have to store billions for this to be effective without lockout. > I realize that's what you were getting at with your replay comment above > but I wanted to re-state it to make sure I understood your suggestion > correctly. While the PG community might be willing to pursue this > approach, I doubt they'd want to seriously increase the size of > pg_authid and, really, to make this work well, how many different stored > hashes would be required for this to be effective at preventing an > attacker who can sniff the network from getting in? We are clearly not > going to store 4 billion entries and I doubt most people would even want > to store more than, say, *10*. Perhaps if we also added an auto-lockout > feature (something I've wanted for quite a while anyway...) this would > work out well. As I said, you can't make this scheme safe against a network attacker. They'd be able to dictionary attack the response, or just mess with the active connection. > One advantage of this approach over password is that the attacker > wouldn't be able to get the actual password very easily and so the > sniffed response would only be usable for the given system, but this > definitely reduces the effectivness of the challenge/response aspect, to > a point where I'm not really sure it's still useful. That is correct. I'm personally in favour of just using 'password' - at-least it's honest. Server-authenticated TLS (eg. verify the server certificate only) or SSH tunnelling are the best ways to secure the network protocol as it stands. Regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
