Re: [OT] Microsoft: Kubernetes clusters hacked in malware campaign via PostgreSQL
От | Stephen Frost |
---|---|
Тема | Re: [OT] Microsoft: Kubernetes clusters hacked in malware campaign via PostgreSQL |
Дата | |
Msg-id | Y9BGKQlciVlnrl8+@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [OT] Microsoft: Kubernetes clusters hacked in malware campaign via PostgreSQL (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Pavel Borisov <pashkin.elfe@gmail.com> writes: > > Regarding the fact that using weak passwords isn't limited, I think > > anyone can write an extension that limits (or advises against) weak > > passwords based on the author's definition of weakness, like checking > > by dictionary or so. That's the power of Postgres extensibility. I > > don't like an idea that Postgres core should enforce some arbitrary > > things like "weakness". > > It's less easy than it sounds, actually, because current best practice > is that the server will never see the cleartext password at all, so > you can't apply the usual litany of weak-password checks. About all > you can do is apply a brute force rainbow attack, which is far from > cheap (although I guess the DBA could run such checks in the background). > Even that might be rendered infeasible if the password is stored as > a SCRAM verifier; I'm not sure about that. Anyway, this is why > contrib/passwordcheck is a development backwater rather than something > people actually use. For better or worse, people do actually use it and it would be much better if we'd actually allow some effort to be put into improving this situation. I'm all for better choices of authentication methods, but that simply isn't always an option and there are cases where DBAs have to be able to require passwords on select accounts be set via cleartext to allow passwordcheck and similar tools to enforce password complexity requirements. Pushing back against that means fewer folks will use PostgreSQL because it isn't able to reasonably address this requirement (unlike most of the other databases out there..), and that's unfortunate. Thanks, Stephen
Вложения
В списке pgsql-bugs по дате отправления: