NIST’s new password rules – what you need to know
nakedsecurity.sophos.com
NIST’s new password rules – what you need to know
1–10 of 237 posts
Re: NIST’s new password rules – what you need to know
#28 characters seems very short.
I like asking people to pick 4 words and a number. Satisfies the length issues.
But... I love emojis and other things being possibilities. Cool.
Re: NIST’s new password rules – what you need to know
#3Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
Re: NIST’s new password rules – what you need to know
#4Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
PCI compliance requires quarterly rotation of passwords and keys.
Re: NIST’s new password rules – what you need to know
#5Alas, Google forces me to use ASCII only passwords:
https://support.google.com/a/answer/33386
Re: NIST’s new password rules – what you need to know
#6Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
PCI compliance requires quarterly rotation of passwords and keys.
This recommendation may perhaps be a step to getting those compliance rules changed.
Re: NIST’s new password rules – what you need to know
#7Looks like some good suggestions:
- Glad they're recommending a stop to the pointless "password must be no longer than (16, 20, ...) characters". Aren't you storing a constant-length hash anyway?
- Why do some logins restrict which ASCII characters can be used? When I see that I can use any symbol from '%!#&' or whatever list they provide, I can only imagine it's a really naive SQL-injection defense. Is there any valid reason for this?
- And glad to see they're recommending against "security challenges". Half the time I'm forced to pick a security question, either none of them apply, a bunch of them are ambiguous ("what's your favorite movie?" - uhh, I'll give you a different answer depending on my mood, etc.), or they're easily searchable ("where did you go to high school?")
Unfortunately I doubt the bad actors will pay too much attention to this. I know Google is planning on dinging sites that don't use HTTPS, is it possible they could ding sites for poor password policies?
Re: NIST’s new password rules – what you need to know
#8Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
I also love that one. I am not yet finding the specific citation in the actual linked repo. I would appreciate it if someone could point it out!
Re: NIST’s new password rules – what you need to know
#9Recommending not expiring based on time is probably my favourite. I've worked at two places where that's been a requirement and my password has always been a passphrase combined with a sequencial number.
PCI compliance requires quarterly rotation of passwords and keys.
Nothing better than rules based on bad data and security theater.
Re: NIST’s new password rules – what you need to know
#10Looks like some good suggestions: - Glad they're recommending a stop to the pointless "password must be no longer than (16, 20, ...) characters". Aren't you storing a constant-length hash anyway? - Why do some logins restrict which ASCII characters can be used? When I see that I can use any symbol from '%!#&' or whatever list they provide, I can only imagine it's a really naive SQL-injection defense. Is there any val…
> Is there any valid reason for this?
If they know that at some point they'll have to ask you to enter your password over a restricted input-method (e.g. on a DTMF keypad.)