Re: [GENERAL] SHA1 on postgres 8.3
От | Sam Mason |
---|---|
Тема | Re: [GENERAL] SHA1 on postgres 8.3 |
Дата | |
Msg-id | 20080404010157.GN6870@frubble.xen.chris-lamb.co.uk обсуждение исходный текст |
Ответ на | Re: [GENERAL] SHA1 on postgres 8.3 (Ron Mayer <rm_pg@cheapcomplexdevices.com>) |
Список | pgsql-hackers |
On Thu, Apr 03, 2008 at 04:42:47PM -0700, Ron Mayer wrote: > Sam Mason wrote: > >On Thu, Apr 03, 2008 at 07:07:56PM +0200, Svenne Krap wrote: > >> > >>ID serial > >>Username varchar > >>Password_md5 varchar > >>Password_sha1 varchar > >... > >Why not just use SHA-512, you get many more quality bits that way. > > Or if he just wanted to use builtin tools and reduce accidental > collisions almost exactly the same much as he propopses, he could use > > password_md5_with_salt_xxx varchar > password_md5_with_salt_yyy varchar > > but I also can't see the point. Won't he have more > collisions from cosmic rays turning the results of his comparisons > from false to true anyway? There's a difference between random bit flips, which in large systems happen surprisingly regularly, and a determined attacker. You'd be able to get somewhere against the former by duplicating everything, and you'd be able to get somewhere against the latter by using stronger hashes. Or have I missed the point entirely. > >Sounds like a good reason for moving the current md5 function out into > >pgcrypto as well! :) > > I'd rephrase it as saying "a good reason for making it less > intimidating to install modules". +1 to all the approaches > that make this less scary. That's a much nicer way of saying it! I think that from an ISPs perspective (I can't remember the real use case that was given recently) the main problem with modules is that you have to build trust in each one individually. I.e. Doesn't the code running in modules run as the postgres user? If so, what would stop a malicious module from doing anything that the postgres user can? I'd probably phrase this as saying the modules are within PG's trust boundary, rather than outside. It's therefore the responsibility of the person installing the module to verify (I think this will generally be blind human trust) that the code isn't malicious. I'd guess that's a reason why so few modules are installed, it basically opens your code up to another source, with whom the installer has no prior trust relationship. There are operating systems that allow authority to be attenuated arbitrarily finely (i.e. not the very coarse user/role based ACL systems we have at the moment) which would allow mutually suspicious code to function. I.e. PG would be able to assume that the module was malicious and that the module wanted to crash PG, the module would assume the reverse, and the ISP wouldn't have to worry at all. It'll be a few years before we get there though. Sam
В списке pgsql-hackers по дате отправления: