top | item 37175755

(no title)

allanbreyes | 2 years ago

NIST dropped the password change recommendation a while back [1] but it still lingers on. The staying power and long tail of this deprecated advice is unfortunate, to say the least.

I don't personally agree that short sessions is bad advice, but Phil Venables has an article that you might enjoy, "Ceremonial Security and Cargo Cults" [2]

[1] https://pages.nist.gov/800-63-FAQ/#q-b05

[2] https://www.philvenables.com/post/ceremonial-security-and-ca...

discuss

order

rspeele|2 years ago

My experience with security auditors from big firms is that they have a checklist including recommendations like 90-day password changes, composition rules, and so on, and will probably never get rid of those.

You may be able to explain to the assessor that "we don't force password changes because NIST no longer recommends it", and they may be sympathetic, but they are still ultimately going to deliver a report that you got dinged on two items because you answered those parts of their questionnaire "wrong".

I have had issues raised for a site having a robots.txt file. NOT that there was a sensitive URL listed in the robots.txt file, or that we were using it to try to hide stuff that wasn't locked behind authentication. Just that we had one at all.

It ends up being way easier to just get rid of it and comply, than try to explain to multiple people at different levels of management how robots.txt works and how it could be associated with vulnerabilities due to misguided usage while also having NOTHING to do with security when used properly.

throwaway03626|2 years ago

Reminds me of the anti virus software at work many years ago that did not allow me to download a password encoding library, because the filename contained the word "password"

I've also experienced automatic security reports that complain that the configuration file contains the word "password" (as in "database.password="). I had to argue with them that we did not actually store passwords in Git as they could clearly see, but that it was set using a environment variable by a secrets manager when actually running in a container. Next time we had a similar use case we would just give it a different name to avoid this complication