On Sat, Mar 7, 2015 at 01:56:51PM -0500, Stephen Frost wrote: > * Bruce Momjian (br...@momjian.us) wrote: > > On Sat, Mar 7, 2015 at 12:49:15PM -0500, Stephen Frost wrote: > > > Ok, this is the incremented counter approach you brought up previously. > > > Using the term 'cluster-wide salt' confused me as I thought you were > > > referring to changing the on-disk format somehow with this. > > > > Yes, I used the term cluster-wide salt in two cases: first, > > cluster-wide counter for the MD5 session salt improvement, and second, > > cluster-wide fixed salt to prevent pg_authid reuse, but to allow reuse > > if the cluster-wide fixed salt was set to match on two clusters, e.g. > > for pooling. > > Ok, how, in the second case, is pg_authid reuse prevented unless we also > change the on-disk pg_authid format? It doesn't matter if there's a
Yes, the second use would be a new authentication method. > different counter used between different clusters, if the attacker has > what's in pg_authid then they can trivially add any salt we send them > during the challenge/response to the pg_authid value and send us the > response we expect. It would be a server-fixed salt sent to the client and applied before the session salt. The pg_authid value would also store with this salt. Again, I am brainstorming about poolers. > > > > The big win for this idea is that it requires no client or admin > > > > changes, while your idea of using a new salt does. My personal opinion > > > > is that the 32-bit counter idea improves MD5 replays, and that we are > > > > better off going with an entirely new authentication method to fix the > > > > pg_authid vulnerability. > > > > > > There's apparently some confusion here as my approach does not require > > > any client or admin changes either. If users are not using TLS today > > > > Really? From your previous email I see: > > > > > this approach looks like this: pre-determine and store the values (on a > > > per-user basis, so a new field in pg_authid or some hack on the existing > > > field) which will be sent to the client in the AuthenticationMD5Password > > > message. Further, calculate a random salt to be used when storing data > > > in pg_authid. Then, for however many variations we feel are necessary, > > > calculate and store, for each AuthenticationMD5Password value: > > > > How do you generate these X versions of password hashes without admin > > changes? In fact, I am not even sure how the server would create these > > unless it had the raw passwords. > > Ok, I've apparently not been clear enough with the proposal. What we > are hashing is the *current value* of what's in pg_authid- which we've > already got on disk. All we have to do is read the current on-disk > value, add a salt to it, and store it back on disk. We'd want to store > more than one, as discussed, since otherwise the challenge/response is > utterly useless. Oh, that is very interesting. It seems like you are basically applying my server-fixed salt idea, except you are doing it X times so sniffing and then replay is less of a problem. Hmmm. I am very glad there is no admin work --- I did not realize that. It does make the trade-off of your idea more appealing, though I still think it weakens MD5 in an unacceptable way. > > > then they will be slightly more susceptible to network-based sniffing > > > > Slightly? X versions as stored in pg_authid vs 16k or 4 billion? > > Sadly, yes. It's not a perfect test, but a simple: > > time for a in `seq 1 1000`; do nc localhost 5432 < /dev/null; done > > Gave me 9.15s, or ~0.00915s per connection on a single thread. That > times 16k is 146s or about two and a half minutes. Of course, I'm > comparing this against what we currently do since, well, that's what we > currently do. Changing it to 4b would certainly improve that. Of > course, using multiple threads, having multiple challenge/responses on > hand (due to listening for a while) or simply breaking the MD5 hash > (which we know isn't a terribly great hashing algorithm these days) > would change that. Uh, my calculations show that as 434 days of trying. (Not sure why you didn't bother doing that calculation.) I think anyone who is worried about that level of attack would already be using MD5. Again, MD5 is mostly used in low-security settings where you just don't want the password sent over the wire in cleartext. Frankly, without TLS, you are already sending your queries and data across in clear-text, and there are other attack vectors. > > > attacks than they are today due to the replay issue, but they are > > > already at risk to a variety of other (arguably worse) attacks in that > > > case. Further, we can at least tell users about those risks and provide > > > a way to address them. > > > > Right, but again, the user can choose to use TLS if they wish. I think > > you are saying MD5 replay security is worthless without TLS, but I can > > assure you many users are happy with that. The fact this issue rarely > > comes up is a testament to that, and in fact, until we documented > > exactly how MD5 worked, we got many more questions about MD5. Perhaps > > we should document the pg_authid reuse risk. > > We should certainly document the pg_authid reuse risk. For my part, I > don't think it's that people are happy with that trade-off but rather > that they simply don't realize the risk is there because, basically, who > would ever do that? I'm not aware of any other server application which > even offers an option to store the authentication token out on disk in a > format which can be trivially used to authenticate to the system > (excluding people who are storing cleartext passwords..). Yes, good point. > I do feel that people who are worried about MD5 replay security who are > *not* using TLS have not considered their risks properly. It is unclear > to me why anyone should feel safe from an attacker who is able to sniff > the network traffic thanks to our challenge/response protocol. > > > > Further, we can provide a solution to the replay concern by encouraging > > > use of SSL/TLS. We can not provide any solution to the pg_authid-based > > > risk with this approach (with the possible exception of recommending > > > password-based auth, though the poor salt used makes that less > > > effective than md5 with the suggestion I've outlined). > > > > > > The incremental counter approach implies not using the approach I've > > > outlined, which is fine, but it doesn't change the pg_authid risk, nor > > > does it help at all for TLS-using environments, and for users who are > > > not using TLS, it doesn't make them particularly more secure to > > > cleartext-password loss, connection hijacking, data loss, or anything > > > except replay attacks. When it comes to risks, for my part at least, I > > > don't feel like the replay risk is the largest concern to an operator > > > who is not using TLS. > > > > Well, users have a tool kit of options and they can choose what they > > want. > > Can they? > > How are they able to prevent an attacker who has gained access to > pg_authid from logging in? What if the attacker gained access to the > replica or an unencrypted backup? I agree that a user can, and should, > do their best to secure the pg_authid file, but there are good reasons > why cleartext password or authentication tokens shouldn't be stored on > disk directly. Fine, but causing MD5 to be less secure doesn't warrant fixing it this way. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
