Re: Password authorization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



In general, it seems to me that many information security professionals strengthen security for the sake of security itself, forgetting for a long time about its original purpose. I have seen situations where password checking rules were so complex that employees had to collectively come up with predictable password generation schemes, which meant that passwords were not only predictable in the historical context of the individual user, but of the group as a whole.
--
Regards, Dmitry!


пт, 21 янв. 2022 г. в 04:12, Scott Ribe <scott_ribe@xxxxxxxxxxxxxxxx>:
> On Jan 20, 2022, at 3:52 PM, Gavan Schneider <list.pg.gavan@xxxxxxxxxxx> wrote:
>
> On 21 Jan 2022, at 3:24, Daulat wrote:
>
>> Yes, you are right, I am planning for password complexity rules and to, force users to change their password.
>>
> While you are in the planning stages you may wish to review current best practice, e.g., USA National Institute of Standards and Technology.
>
> For me the most interesting aspect of the revised standard is how forcing password changes and complexity rules often leads to reduced security in the real world.
>
> Refer:
> https://pages.nist.gov/800-63-3/sp800-63-3.html
> https://auth0.com/blog/dont-pass-on-the-new-nist-password-guidelines/ (for a more human readable version :)
>
> Regards
>
> Gavan Schneider

Slightly off-topic, but I once ran into a system that would not allow kk1bsk#$ as a password because it contained a dictionary word.

Still wondering what dictionary they were using...





[Index of Archives]     [Postgresql Home]     [Postgresql General]     [Postgresql Performance]     [Postgresql PHP]     [Postgresql Jobs]     [PHP Users]     [PHP Databases]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Yosemite Forum]

  Powered by Linux