
NIST advises services to not require that passwords be changed periodically - jbuzbee
http://www.ibtimes.com/my-password-secure-nist-advises-against-periodically-changing-passwords-2541293
======
Spare_account
NIST doesn't "Advise Against Periodically Changing Passwords". There is no
issue with periodically changing passwords in and of itself.

NIST is acknowledging that the typical user when faced with a password policy
that _requires_ a regular password change will choose a weaker password. NIST
is advising against imposing a _requirement to_ periodically reset passwords.

Maybe I'm nitpicking but the title as it currently stands is misleading in my
opinion.

~~~
dsacco
I disagree. In principle, every time a password is changed is a point of
failure - it's additional overhead that has the opportunity to go wrong. If a
password does not need to be changed, don't change it. Set it and forget it.

If you generate strong passwords, store them securely in a password manager
and use different passwords for each account, you shouldn't need to force a
password change unless the password is compromised or technology evolves to
make it insecure.

~~~
chronic940
> store them securely in a password manager and use different passwords for
> each account​

You are about the 2% of the tech crowd (i.e, bay area software/data people).
The vast majority of engineers do not use a password manager, let alone the
entire US populace.

You severely overestimate the amount the average person cares about password
security.

~~~
wayn3
id much rather have a reasonable solution for widespread 2 factor
authentication than this password mess.

with my bank i have a password, an app on my phone that generates a key and if
i perform significant transactions, they call me to confirm before processing
it.

the idea that i'm going to use a different password for every stupid site out
there that i have an account with is a bit silly. if someone desperately wants
to compromise some of them then so be it. hijack my twitter if it makes you
feel better. im not going to waste mental energy on securing social media.

"just use a password manager" sounds cute. password managers are compromised,
too. password managers are about as trustworthy as the people who operate
them. theres no way im handing my passwords for bank accounts over to some
random company and for passwords that protect pointless internet nonsense, im
not going to use one either because its irrelevant.

you can invoke this whole "password managers are secure" hoohaa. if they
ACTUALLY encrypt your passwords properly and ACTUALLY dont save them on their
own servers for whatever they want to do with them later, then yes, they
probably are secure. but theres no way to be sure that thats the case.
Trusting a password manager introduces more uncertainty into your password
woes than they will ever make you more secure, if you really think this whole
thing through.

the other issue with a password manager is that in theory, they work across
platforms. that ends rather abruptly when youre not in a browser and need to
enter a password into an app on your phone.

~~~
interfixus
You seem to be operating under the assumption that all password managers are
netbased and commercially operated.

This is not the case for PasswordSafe, not the case for the various Keepass
implementations out there, and not the case for several other, lesser known
projects.

I am a happy, contended and reasonably safe KeepassX user since many years
ago. While I do see the point of two factor auth in certain situations, I
sincerely hop and pray it never takes off in a mandatory big way, uncalled for
annoyance as it is in most cases. My 36 character passwords usually do the job
just fine.

------
lholden
"The National Institute of Standards and Technology (NIST) is no longer
recommending people periodically change their passwords as part of the
organization’s new draft of its Digital Identity Guidelines."

Untrue, misleading, and possibly harmful.

NIST isn't recommending _USERS_ stop changing their passwords. That would be
insane. They are recommending that services stop enforcing periodic password
changes on users because it ends up hurting the user in the long run. (Ie,
passwords should be easy for users and hard for attackers).

~~~
ScottBurson
I think the keyword is "periodically". They're not saying not to change
passwords for any reason; they're just saying not to do it _solely_ because
the password has been in use for some fixed amount of time. That
recommendation applies to users as well as to services setting password
policy.

------
LinuxBender
NIST have an interesting history around security. One such example would be
AES. They favored Rijndael over Serpent, despite Serpent clearly winning on
technical merit. Also, Rijndael is the one cipher that intel have offloaded on
their chips and even called it AES-NI vs. offloading several ciphers.

I agree with some comments here that size matters. It is trivial to put a
series of characters in between 2 to {n} words you can easily remember.

____This____Is____Number____42!____ and I would remember it is 4 _'s around
each word because there are 4 words/numbers.

More sensitive content should equate to more words; and therefore, more of the
buffer characters.

You can even use this to defeat keyloggers. Open up a prompt that you can type
in, then type a bunch of a character. Then use your mouse to select the number
of characters that represents your buffer character length, or a portion of
it. Then copy-paste as required. Keyloggers will capture cntr-v but they won't
capture how many characters you selected.

For those concerned about password managers and keyloggers, don't put your
actual password in them. Leave off something, somewhere in your password.
Maybe the start of your pw actually contains buffer characters that you know
to type or paste.

A majority of folks won't be bothered to do any of this. I am just sayin',
it's super easy once you train yourself.

~~~
tptacek
This is a weird comment.

First and most importantly, you have the chronology backwards --- obviously,
Intel implemented AES-NI _after_ NIST chose AES. If NIST had chosen Serpent,
AES-NI would implement Serpent. That's the point of encryption standards.

Second, Serpent had a higher security margin, but was slower, and more
complicated; among other issues, Serpent has a higher hardware footprint. None
of the AES finalists have been meaningfully weakened since AES was selected.

There are obviously sketchy NIST crypto standards, and at least one very bad
one. AES isn't either of those kinds of things.

~~~
LinuxBender
> First and most importantly, you have the chronology backwards

No, you and I are saying the same thing. Perhaps I worded it poorly? My point
is they are fixating on a specific cipher they believe everyone should and
will use. As it turns out, most are because Intel backed their choice and gave
people incentive to utilize it.

~~~
tptacek
Again, that would be the point of an encryption standard.

~~~
LinuxBender
If fixating on a specific cipher is considered to be a standard, then let's
deprecate it. I believe that was done in error. The standard should be around
how each cipher is implemented in a secure manor, not limiting options to one
cipher.

By diversifying options, brute force attempts get exponentially more
expensive. It would be easy enough to list in CPU capabilities which
instructions are supported.

~~~
tptacek
None of this makes sense, sorry.

~~~
toast0
I think what LinuxBender may be trying to say is that if everyone standardizes
down to a single cipher, that's not a good thing when that one cipher is shown
to be a poor choice. It might be nicer if people have a few choices, so we
have freedom to disable some of them when one becomes a poor choice.

Ex: when TLS clients and servers commonly supported 3DES, RC4, and AES, it
wasn't universally painful to disable 3DES and RC4 (although if you
support(ed) embedded clients without AES support, it's still painful). I think
ChaCha looks to be a second good option that's gaining support.

~~~
tptacek
I like ChaCha. I like AES. Systems should choose one or the other. Part of the
point of ChaCha is to exploit the capabilities of general-purpose processors
to get fast encryption without special-purpose hardware acceleration.

What people should _not_ do is cascade ciphers, or, even worse, build systems
that allow for cipher negotiation. Every system that negotiates has been a
disaster.

~~~
LinuxBender
If I were an intelligence agency or signal intelligence, I might argue for
this so that I can narrow my attacks to one cipher. Perhaps the mafia or
cartel would benefit from this. I can't imagine any other rational to argue
for standardizing on a single cipher.

~~~
Tomte
Interoperability. Limiting resources (hardware implementation for AES on chip,
as opposed to hardware implementations for n ciphers).

------
milkthefat
This is great, unfortunately considering this is only draft I imagine it will
be a considerable amount of time to trickle down through the "compliance
standards" we are required to enforce. I do look forward to the day I no
longer have to change my password every 30 days though.

~~~
tyingq
Agreed. As it stands today, PCI, Sarbanes Oxley, HIPPA, and other drivers are
used as hammers to force password change policies.

Even if they don't mention it directly, some audit firm tosses it in as a best
practice to support something more generically stated in the standards.

------
rocky1138
This is a terrible article which autoplays a loud video and has a misleading
title.

------
antaviana
I would say that the main reason for periodically changing a password is to be
better protected from data theft in those who store the password (read yahoo
hack and family).

That said, I hate changing passwords.

------
jamesaross
"In addition to ditching the requirement for regular password changes, the
NIST is also advising sites to allow users to create passwords that are at
least 64 characters long and include spaces so people can create pass phrases
that may be easier to remember and to ditch special character requirements."

Relevant XKCD: [https://www.xkcd.com/936/](https://www.xkcd.com/936/)

------
hackbinary
Uhg, ibtimes is one of those annoying sites that autoplays video.

There is chrome plugin that blocks autoplay for video and audio, but you then
have to give it rights to access all data on webpages. How does this square
with with online purchases where you put your credit card in?

------
5706906c06c
The problem is that most have adopted password managers and two-factor, which
means the guideline will be largely ignored.

~~~
interfixus
Most? Do you really think so?

In my experience, the vast majority of everybody is still bumbling ahead with
post-it notes and simple, memorised passwords shared all across the board.

~~~
5706906c06c
I'm so sorry for you and your job, I guess.

------
newman314
I think this is silly.

Anecdotally, I've had good success forcing longer passwords while at the same
time, introducing people to password managers. Doing only one or the other
does not have the same uptake but we recently went through and forced everyone
to reset their passwords. We're now up to 16 chars, I'd like to get to 30 (or
to a point where it's a pain to type it in) but baby steps, I suppose.

~~~
csydas
We took a different approach at my last job when we revisited our entire
identity management approach. We were a University with Federated logins
across a few dozen system, and our password rules had honestly spiraled out of
control because the system hadn't been constructed in such a way to restrict
access easily.

During the rework, we focused on a few things primarily:

1\. Reduce password complexity, enforce legnth 2\. Restructure account
creation around least-privilege principal, so that access had to be granted,
not just created during account creation, and also allow fast and easy
addition and removal of access to system as part of the Management System 3\.
Revisit password expiries based on level of access and relative strength of
password (as determined by zxcvbn)

Students and low level staff loved it - if you had a standard account and
didn't have any access to anything sensitive that didn't belong to you, your
password could sit untouched for up to 2 years I think if it met the strength
requirements.

Those with access to actual sensitive data (student records, finances, etc),
were held to a higher class of password complexity and would suffer a rotation
penalty if they didn't have a sufficiently complex password; this mostly did
away with the number of people with very common passwords, though it didn't go
without a lot of fighting for some of the administrators, which, as I remember
the discussions anyways, were more pride issues than anything. We used that as
an opportunity to roll out password managers

~~~
kevhito
Can you back up these recommendations with actual studies or research papers?
Or are you just making up your security strategy by gut instinct here?

~~~
ScottBurson
Even if it's the latter, they're actually thinking about what they're trying
to protect and what system would work best to protect it. That has got to be
an improvement on the mindless, cargo-cult approach to security that most
organizations take.

