Conversation

Notices

1. Embed this notice
   Free Teks for sale, cheap (tek@freeradical.zone)'s status on Sunday, 14-May-2023 11:16:14 JST Free Teks for sale, cheap

   While I'm in there anyway, here are some nuggets from NIST SP 800-63B, section 5, "Authenticator and Verifier Requirements", aka password requirements:

   • Embed this notice
     Free Teks for sale, cheap (tek@freeradical.zone)'s status on Sunday, 14-May-2023 11:16:11 JST Free Teks for sale, cheap

     in reply to

     Also, and this is key:

     "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.”

     clacke likes this.
     clacke repeated this.
   • Embed this notice
     Free Teks for sale, cheap (tek@freeradical.zone)'s status on Sunday, 14-May-2023 11:16:12 JST Free Teks for sale, cheap

     in reply to

     5.1.1.1 Memorized Secret Authenticators. "Memorized secrets SHALL be at least 8 characters in length if chosen by the subscriber. Memorized secrets chosen randomly by the CSP or verifier SHALL be at least 6 characters in length and MAY be entirely numeric. [...] No other complexity requirements for memorized secrets SHOULD be imposed."

   • Embed this notice
     Free Teks for sale, cheap (tek@freeradical.zone)'s status on Sunday, 14-May-2023 11:16:12 JST Free Teks for sale, cheap

     in reply to

     5.1.1.2 Memorized Secret Verifiers

     [Password hints suck. Denying bad passwords like ‘aaaaaa’ is fine. Rate limit logins.]

     "Verifiers SHOULD permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.”

     clacke repeated this.
   • Embed this notice
     Free Teks for sale, cheap (tek@freeradical.zone)'s status on Sunday, 14-May-2023 11:16:16 JST Free Teks for sale, cheap

     in reply to

     If you come anywhere near authentication services for a living, you must read NIST 800-63B (https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-63b.pdf). It’s very clear, readable, and useful. And if you require wildly complex passwords, or disable pasting them into web forms, or make users rotate them, you’re violating government standards and best practices. Stop that!

     clacke likes this.
   • Embed this notice
     Free Teks for sale, cheap (tek@freeradical.zone)'s status on Sunday, 14-May-2023 11:16:23 JST Free Teks for sale, cheap

     in reply to

     • Pseudo Nym
     • ${jndi:blit32 💻

     @pseudonym @blit32 Conflicting standards? That never happens!

     clacke likes this.
   • Embed this notice
     Pseudo Nym (pseudonym@calckey.social)'s status on Sunday, 14-May-2023 11:16:28 JST Pseudo Nym

     in reply to

     • ${jndi:blit32 💻

     @blit32@noc.social @tek@freeradical.zone
     
     Complete agree. But some places are stuck between conflicting standards.
     
     PCI-DSS (payment card regs for handling credit cards) still requires periodic (90 days, I think) password rotation. :⁠-⁠(
     
     You can't win.
     
     I'm on team NIST standards.
     
     #infosec

     clacke likes this.
   • Embed this notice
     ${jndi:blit32 💻 (blit32@noc.social)'s status on Sunday, 14-May-2023 11:16:31 JST ${jndi:blit32 💻

     in reply to

     @tek Not only are you violating standards, with the new national cybersecurity strategy you might be liable of violating those standards causes harm to your users.

   • Embed this notice
     mkj (mkj@social.linux.pizza)'s status on Sunday, 14-May-2023 11:16:34 JST mkj

     in reply to

     • Pseudo Nym
     • ${jndi:blit32 💻

     @tek @pseudonym @blit32 If there are conflicting standards, then we must be in need of a unifying standard!

     Thereby invoking https://xkcd.com/927/

     clacke likes this.
   • Embed this notice
     ${jndi:blit32 💻 (blit32@noc.social)'s status on Sunday, 14-May-2023 11:16:35 JST ${jndi:blit32 💻

     in reply to

     • mkj
     • Pseudo Nym

     @mkj @pseudonym @tek I would question the assumption that forcing users to change their passwords improves security. I’ve used the “password1”, “password2” pattern when forced to change passwords frequently and I expect everyone else on the planet has too, does that offer improved security?

     clacke likes this.
   • Embed this notice
     mkj (mkj@social.linux.pizza)'s status on Sunday, 14-May-2023 11:16:37 JST mkj

     in reply to

     • Pseudo Nym
     • ${jndi:blit32 💻

     @pseudonym @tek @blit32 So how about you segregate that? Surely it will improve security if you force people to go through a password reset process every odd few weeks when they need access to that kind of data and have forgotten their password, compared to if you let people set a strong password and just be done with it.

     Also lots of companies force their employees to change their passwords with alarming frequency even when those employees, or even the company, never handle/s credit card info.

   • Embed this notice
     Free Teks for sale, cheap (tek@freeradical.zone)'s status on Sunday, 14-May-2023 11:16:38 JST Free Teks for sale, cheap

     in reply to

     • mkj
     • Pseudo Nym
     • ${jndi:blit32 💻

     @blit32 @mkj @pseudonym That’s exactly why NIST says not to do it. People forced into that goofy system tend to pick crappy, easy to remember passwords.

     clacke likes this.
   • Embed this notice
     Gizmo :blobcatoutage: (gizmo@gremlins.social)'s status on Sunday, 14-May-2023 11:17:38 JST Gizmo :blobcatoutage:

     in reply to

     @tek@freeradical.zone thank you! I knew there was a standard somewhere that said you needed to allow password managers. Now I know what to throw at my boss if/when they start muttering about pasting passwords!

     clacke likes this.
   • Embed this notice
     Drew Mochak (objectinspace@freeradical.zone)'s status on Sunday, 14-May-2023 11:17:39 JST Drew Mochak

     in reply to

     @tek Did some QA for Google back in the day.

     The vendor I worked for had a 90-day password recycling policy (and of course, you could not use an old one.) If you wanted it recovered, you had to call a phone line that would email a PDF of a screencap of your temporary password. (Which I couldn't see, naturally)...

     My work email from google (the one I actually used) had none of these restrictions.

     There is a lesson here, but no one was inclined to learn it.

     clacke likes this.