<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>jchw</author><text>I disagree. It may seem good on paper, but it gives you too much of a false sense of security. Security measures like this often seem to work, but they are papering over a deeper problem. Usually this is being done because user input is not being handled carefully, and if so, the assumption that blocking some keywords &amp;quot;defangs&amp;quot; potential exploits is usually easy to prove false. Consider the case of eBay and JSFuck[1].&lt;p&gt;I dislike the mentality that leads to this; WAFs, lazy pentesting and compliance checkboxes have created a substantial body of absolute bullshit security theater and I have absolutely zero doubt that this has convinced companies it&amp;#x27;s &amp;quot;safe&amp;quot; to put insanely poorly written software partially out on the open internet and that they&amp;#x27;ve &amp;quot;done their due diligence&amp;quot; so to speak. And then I get a letter in the mail apologizing that my most confidential information has yet again been leaked by some company I barely or didn&amp;#x27;t have any real choice to give my data to. I&amp;#x27;m sure they all care deeply about my data and that&amp;#x27;s why it was stolen using decades-old Java serialization library vulnerabilities.&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.checkpoint.com&amp;#x2F;research&amp;#x2F;ebay-platform-exposed-to-severe-vulnerability&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.checkpoint.com&amp;#x2F;research&amp;#x2F;ebay-platform-exposed-t...&lt;/a&gt;</text><parent_chain><item><author>civilized</author><text>I expect this will attract a lot of criticism, but I actually think it&amp;#x27;s a good idea, at least in some cases.&lt;p&gt;There are a &lt;i&gt;lot&lt;/i&gt; of people writing bad code and bad system architectures for their organizations. There are not enough people with the competence, organizational power, and time to catch what&amp;#x27;s bad and force change in those organizations. In the US you are probably forced to do business via many such terribly coded websites, e.g. your local healthcare provider. In such cases, it might be better if we assumed the implementation &lt;i&gt;might&lt;/i&gt; be as awful as it commonly &lt;i&gt;is&lt;/i&gt;, and recommended mitigations based on that.&lt;p&gt;It&amp;#x27;s also easy for people to test if the website actually allows the nominally prohibited password patterns and complain to some oversight authority if so. Whereas it&amp;#x27;s not so easy to test, from the outside, whether it&amp;#x27;s &lt;i&gt;really&lt;/i&gt; been done the right way.&lt;p&gt;It&amp;#x27;s inelegant and tragic, but in the end it might be a good idea to accept that things are often done poorly and without adequate oversight, and consider what mitigations can prevent the worst outcomes in these cases.</text></item></parent_chain></comment><story><title>Password may not contain: select, insert, update, delete, drop</title><url>https://id.uni-lj.si/DigitalnaIdentiteta/PonastavitevGesla?culture=en-GB</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>wongarsu</author><text>If an organization has such a password policy, that can be interpreted as the person in charge of setting this policy thinks their organization doesn&amp;#x27;t have enough people with the competence and organizational power to prevent SQL injection vulnerabilities. Which would reflect poorly on any institution, but especially a university (which should be a bastion of people with competence and organizational power).&lt;p&gt;As for common password advise, my take on your argument would be that we should all be using these keywords in our passwords to quickly surface these bugs, lest they be hidden and only used by attackers.</text><parent_chain><item><author>civilized</author><text>I expect this will attract a lot of criticism, but I actually think it&amp;#x27;s a good idea, at least in some cases.&lt;p&gt;There are a &lt;i&gt;lot&lt;/i&gt; of people writing bad code and bad system architectures for their organizations. There are not enough people with the competence, organizational power, and time to catch what&amp;#x27;s bad and force change in those organizations. In the US you are probably forced to do business via many such terribly coded websites, e.g. your local healthcare provider. In such cases, it might be better if we assumed the implementation &lt;i&gt;might&lt;/i&gt; be as awful as it commonly &lt;i&gt;is&lt;/i&gt;, and recommended mitigations based on that.&lt;p&gt;It&amp;#x27;s also easy for people to test if the website actually allows the nominally prohibited password patterns and complain to some oversight authority if so. Whereas it&amp;#x27;s not so easy to test, from the outside, whether it&amp;#x27;s &lt;i&gt;really&lt;/i&gt; been done the right way.&lt;p&gt;It&amp;#x27;s inelegant and tragic, but in the end it might be a good idea to accept that things are often done poorly and without adequate oversight, and consider what mitigations can prevent the worst outcomes in these cases.</text></item></parent_chain></comment><story><title>Password may not contain: select, insert, update, delete, drop</title><url>https://id.uni-lj.si/DigitalnaIdentiteta/PonastavitevGesla?culture=en-GB</url></story>