zlacker

Also, “Password policies must not require use of special characters or regular rotation.”

They even call out the fact that it's a proven bad practice that leads to weaker passwords - and such policies must be gone from government systems in 1 year from publication of the memo. It's delightful.

>>meepmo+(OP)
I am a bit concerned that this will be read as "Password policies must require the use of no special characters", possibly as a misguided attempt to push people away from adding using "Password123!" as the password. I wish the memo had spelled out a little more clearly that there's nothing wrong with special characters, but they shouldn't be required. Also, is a whitespace a special character?

>>CGames+B7
If we were to stop using special characters and only use human friendly phrases (eg “jupiterIsTheSmallestPlanet”) it wouldn’t be the end of the world.

>>meepmo+(OP)
Somewhat unrelated, but hopefully this also means TreasuryDirect will get rid of its archaic graphical keyboard that disables the usage of password managers.

(Graphical keyboards are an old technique to try to defeat key loggers. A frequent side effect of a site using a graphical keyboard is that the developer has to make the password input field un-editable directly, which prevents password managers from working, unless you use a user script to make the field editable again.)

>>atulad+Sc
Just saying in this in case it will help you. For treasurydirect, you can use inspect element and change the value="" field on the password element, and paste in your password from your password manager. It's not as convenient as autofill from your password manager, but it sure beats using the graphical keyboard.

>>meepmo+(OP)
Yeah, while the clear and correct focus overall is on moving away from passwords entirely (FINALLY!!!!!) it's still nice to see something immediately actionable on at least improving policies in the mean time since those should be very low hanging fruit. Although one thing one thing I don't see is a mention of is doing away with (or close enough) password max character limits and requiring that everything get hashed step 1. Along with rotation and silly complex rules, stupid low character limits is the other big irritation with common systems. If passwords must be used they should be getting hashed client-side anyway (and then again server-side) so the server should be getting a constant set of bits no matter what the user is inputting. There isn't really any need at all for character limits at this point. If anything it's the opposite, minimums should be a lot higher. If someone is forced to use at least 20-30 characters say that essentially requires a password manager or diceware. And sheer length helps even bad practices.

But maybe they didn't bother giving much more effort to better passwords because they really don't want those to stick around at all and good for them. Password managers themselves are a bandaid on the fundamentally bad practice of using a symmetric factor for authentication.

>>meepmo+(OP)
To be fair, this was part of the NIST guidelines since Mar 2020. A whole appendix was added to justify it: https://pages.nist.gov/800-63-3/sp800-63b.html#appA

>>moored+HF
Way earlier than that, even.

> Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets

Earliest draft in Wayback Machine, dated June 2016. Lots of other good stuff from 800-63 dates back this early too.

https://web.archive.org/web/20160624033024/https://pages.nis...

>>gkop+GM
SHOULD NOT and MUST NOT are very different from a compliance perspective.

The former usually means something between nothing at all and “you can do it but you have to write paperwork that no one will actually read in detail, but someone will maybe check the existence of, if you do”.

The latter means “do it and you are noncompliant”.

>>dragon+AQ
https://datatracker.ietf.org/doc/html/rfc2119 is a good reference, although those precise definitions may or many not be in effect in any particular situation (including this one).

See also https://datatracker.ietf.org/doc/html/rfc6919

>>meepmo+(OP)
I worked for the govn't ~20 year ago - in IT - and even I hated our password policies. I just kept iterating the same password because we had to change it every 6 weeks.

>>dragon+AQ
Thanks for pointing out the improvement over NIST, it wasn’t clear to me. But did you mean to reply to my parent? Both the draft and the current language say SHOULD NOT. I’d rather “must”, but will settle for “should”; the NIST docs have certainly made my work easier. Hopefully NIST improves, and perhaps this memo will help!

The essential purpose of my comment was only to correct my parent on the date.

>>gkop+GM
They accepted edits via pull request when that was in the works! [1] Such a better model of giving feedback or suggesting edits compared to sending in a marked-up PDF.

[1]: https://github.com/usnistgov/800-63-3/pull/576

>>pm90+da
But if a whitespace is not a special character (or punctuation) we can add entropy with "Jupiter is the smallest planet!" while still being human readable and using the passphrase paradigm.

>>tbirdz+pd
Thanks! That would definitely be a way to do it. I was hinting at something similar by saying "unless you use a user script to make the field editable again". You could also run a bookmarklet that makes the input editable using JavaScript, and then using the password manager. But it's a pain in any case if you're using the site on a mobile device.