Re: [GENERAL] Salt in encrypted password in pg_shadow
Greg Stark wrote: Gaetano Mendola [EMAIL PROTECTED] writes: Well, when SHA-0 was ready NSA suggested to apply some changes in order to correct some flaw discovered and SHA-1 comes out, interesting NSA never wrote which flaw was corrected! May be SHA-1 is trasparent water to NSA eyes :-) This is awfully similar to the story that's told about DES: When DES was under development the NSA told people to try a few specific constants for the sboxes stage of the cipher. As far as anyone at the time could tell they were completely random values and nearly any value would have been just as good. Then 30 years later when differential cryptanalysis was invented people found the values the NSA told them to use are particularly resistant to differential cryptanalysis attacks. Almost any other values and DES would have fallen right then. This means it's quite possible the NSA had differential cryptanalysis 30 years before anyone else. Quite a remarkable achievement. However it's unlikely that the same situation holds today. 30 years ago nobody outside the government was doing serious cryptanalysis. If you were a mathematician interested in the field you worked for the NSA or you changed fields. These days there's tons of research in universities and in the private sector in serious cryptanalysis. The NSA still employs plenty of good cryptanalysts but they no longer have the monopoly they did back then. I will invite you to repeat the same sentence in 2034 ... :-) Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Salt in encrypted password in pg_shadow
Tom Lane [EMAIL PROTECTED] writes: it's unlikely that the same situation holds today. Why would you think that? The US government may not have too many clues, but they certainly understand the importance of crypto. I cannot think of any reason to suppose that NSA et al would have stopped spending serious effort in this area. Certainly the NSA hasn't stopped spending serious effort. What's changed is that now there is serious effort outside the NSA as well. In academia and the private sector, not to mention other national governments. That wasn't the case 30 years ago partially because the money just wasn't there outside the NSA, and partially because the NSA was extremely persuasive in hiring away anyone doing research. It's hard to do get ahead in publish-or-perish academia when everything you're working on suddenly becomes classified... (Where serious effort is measured by the standard of a billion here, a billion there, pretty soon you're talking about real money.) Well there's a limit to how much you can spend on researcher salaries. There are only so many researchers available to hire. Of course we don't know what their full budget is but if it's in the billions (which it may well be) it's probably mostly spent on operational costs, not research. Quite honestly, as a US taxpayer I would not be happy if the NSA were not far ahead of public research in this field ... It's presumably ahead. But not like the situation 30 years ago when they were the only group doing this kind of research. -- greg ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Salt in encrypted password in pg_shadow
Greg Stark [EMAIL PROTECTED] writes: This means it's quite possible the NSA had differential cryptanalysis 30 years before anyone else. s/quite possible/known fact/ Quite a remarkable achievement. However it's unlikely that the same situation holds today. Why would you think that? The US government may not have too many clues, but they certainly understand the importance of crypto. I cannot think of any reason to suppose that NSA et al would have stopped spending serious effort in this area. (Where serious effort is measured by the standard of a billion here, a billion there, pretty soon you're talking about real money.) Quite honestly, as a US taxpayer I would not be happy if the NSA were not far ahead of public research in this field ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Salt in encrypted password in pg_shadow
On Wed, Sep 08, 2004 at 00:33:39 -0400, Tom Lane [EMAIL PROTECTED] wrote: I've been hearing rumblings that MD5 and all other known crypto protocols are known vulnerable since the latest crypto symposiums. (Not that we didn't all suspect the NSA et al could break 'em, but now they've told us exactly how they do it.) Things aren't currently that bad. So far people have found a way to find two strings that give the same hash using MD5. They haven't yet found a way to find a string which hashes to a given hash. SHA-0 was also shown to have some weakness. From comments I have read, I don't think SHA-1 was shown to have any weaknesses. One comment specifically mentioned that the change made between SHA-0 and SHA-1 seems to have been made to address the weakness found in SHA-0. I haven't read the source papers, so take this all with a grain of salt. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Salt in encrypted password in pg_shadow
Tom Lane wrote: I read that the password hash in pg_shadow is salted with username. Is this still the case? If so, since probably 99% of all PostgreSQL has postgres as the superuser name, wouldn't it be better to use standard Unix/Apache MD5 hash instead? How does that improve anything? If we add a random salt into it, we'd have to store the salt in pg_shadow, so there wouldn't be any secrecy added --- an attacker who can read pg_shadow could see the salt too. Consider someone who creates a long list of: MD5( postgres + ) MD5( postgres + aaab ) MD5( postgres + aaac ) ... Now if he has access to other people's pg_shadow, he can compare the hashes with his dictionary. Replacing postgres with a random salt defeats this dictionary attack (and thus he will have to resort to brute force). (Actually, an attacker who can read pg_shadow is already superuser, so it's not clear there's anything left to hide from him anyway.) But consider someone who finds a harddisk or tape containing a database backup... he can then gain access to the real, online database. -- dave ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Salt in encrypted password in pg_shadow
David Garamond wrote: Consider someone who creates a long list of: MD5( postgres + ) MD5( postgres + aaab ) MD5( postgres + aaac ) ... Now if he has access to other people's pg_shadow, he can compare the hashes with his dictionary. Replacing postgres with a random salt defeats this dictionary attack (and thus he will have to resort to brute force). But surely you have to store the random salt in pg_shadow too? Or am I missing something? -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Salt in encrypted password in pg_shadow
Richard Huxton [EMAIL PROTECTED] writes: David Garamond wrote: Consider someone who creates a long list of: MD5( postgres + ) MD5( postgres + aaab ) MD5( postgres + aaac ) But surely you have to store the random salt in pg_shadow too? Or am I missing something? I think David is suggesting that the hypothetical attacker could gain economies of scale in multiple attacks (ie, if he'd been able to steal the contents of multiple installations' pg_shadow, he'd only need to generate his long list of precalculated hashes once). I think this is too far-fetched to justify an authentication protocol change though. Also, MD5 hashing is fast enough that I'm not sure the above is really significantly cheaper than a straight brute-force attack, ie, you just take your list of possible passwords and compute the hashes on the fly. The hashes are going to be much longer than the average real-world password, so reading in a list of hashes is going to take several times as much I/O as reading the passwords --- seems to me that it'd be cheaper just to re-hash each password. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Salt in encrypted password in pg_shadow
Tom Lane wrote: I think David is suggesting that the hypothetical attacker could gain economies of scale in multiple attacks (ie, if he'd been able to steal the contents of multiple installations' pg_shadow, he'd only need to generate his long list of precalculated hashes once). I think this is too far-fetched to justify an authentication protocol change though. Also, MD5 hashing is fast enough that I'm not sure the above is really significantly cheaper than a straight brute-force attack, ie, you just take your list of possible passwords and compute the hashes on the fly. The hashes are going to be much longer than the average real-world password, so reading in a list of hashes is going to take several times as much I/O as reading the passwords --- seems to me that it'd be cheaper just to re-hash each password. Many people use short and easy-to-guess passwords (remember we're not talking about the superuser only here), so the dictionary attack can be more effective than people think. And considering many people use the same password for several things, Postgres could become one of the easy sources to get/guess people's plaintext passwords from hacked machines. At least Apache and Unix have been random-salting passwords for a while now. However, I realize this will break the current MD5 hash, probably too painful to do at the moment. Perhaps for the future, non-MD5 hash... -- dave ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Salt in encrypted password in pg_shadow
David Garamond [EMAIL PROTECTED] writes: Tom Lane wrote: Also, MD5 hashing is fast enough that I'm not sure the above is really significantly cheaper than a straight brute-force attack, ie, you just take your list of possible passwords and compute the hashes on the fly. The hashes are going to be much longer than the average real-world password, so reading in a list of hashes is going to take several times as much I/O as reading the passwords --- seems to me that it'd be cheaper just to re-hash each password. Many people use short and easy-to-guess passwords (remember we're not talking about the superuser only here), so the dictionary attack can be more effective than people think. And that responds to the speed argument how? I quite agree that a guessable password is risky, but putting in a random salt offers no real advantage if the salt has to be stored in the same place as the encrypted password. regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
