
Digital Identity Guidelines: Public Comment Period - tuxxy
https://pages.nist.gov/800-63-3/
======
retox
My banks online password requirements match the suggestions in these
documents, but the passwords are entirely case insensitive. So its the same if
I type "password" or "PaSSwOrD". There is a second passphrase that youre asked
to select randomly chosen characters from combo boxes for, but that is case
insensitive also. I got into an argument with their customer rep on Twitter
about this not being the best case and they replied that it was based on
industry best practice. I've never heard that before...

~~~
mataug
When passwords are case insensitive I'm always skeptical that they are storing
passwords in plain text.

Ofcourse they could be using a function to change the case before putting it
through a oneway function but it just adds to the suspicion.

The other horrid offence that I see banks make is preventing users from
pasting / autofilling their passwords. This just asks for people to use common
easy to guess passwords instead of a password manager.

~~~
hvidgaard
A password should be hashed client side, and lowercasing (or upper casing)
before hashing would be trivial and just as secure if you accept that the
searchspace is reduced.

~~~
throwawaysbdi
Eh, if you're using TLS it really doesn't matter where you hash. There's a lot
of arguments for not doing secure hashing and encryption in JavaScript

~~~
hvidgaard
If I hash client side the server will never know my password. If the server
hashes the password, that is effectively the same as storing the password in
cleartext.

/edit: Security wise sending the password, means you trust the server to
handle the password correctly. For all we know it stores the plaintext
password. If we send the hash, we KNOW that it does not store the password.
It's an important distinction to make in real world systems. No matter how
much best practices dictates to not reuse passwords, it happens as long as
humans are involved.

~~~
ykler
(Note: edited to make it more clear that hashing only on the client is
insecure.) I think it is true that hashing on the client in addition to on the
server offers a little security boost since if someone is able to snoop a
login, they will only see a hashed password, which they can use to compromise
the user's account on the site being accessed but not on other sites where the
user may use the same password (assuming you use a salted hash). Server
hashing guards against the case where someone steals the database but not
against the case where they snoop logins (and hashing _only_ on the client
wouldn't guard against this). Also, it might be practical to use more rounds
of bcrypt on the client, but this is hard to say. Maybe you were downvoted,
though, because you said server hashing is "effectively the same as storing
the password in cleartext." Actually, the main win is probably from hashing on
the server; the boost from also doing it on the client seems relatively minor.

~~~
hvidgaard
If we send the plaintext password we don't know that the server handles it
responsibly. We don't know if they had to push an update under time constraint
means that they now store passwords in plaintext. What we know is that we send
plaintext password to the server on every login, that should, in a threat
model, be considered as not using hashing at all.

On the other hand, if the password is hashed client side, we KNOW that it
cannot be stored as plaintext, because the server never knows it.

~~~
JetSpiegel
If you hash the password on the client, that hash IS the password. The
attacker can just replay that request and can authenticate as you.

~~~
hvidgaard
That is not the issue we're protecting against, but preventing a leak from
affecting other sites when the user is reusing a password.

~~~
simcop2387
I've done this before in a site, probably badly. But the way I handled it is
that on sign up I hashed the password on the client side and stored that once.
Then during login as part of the form I also included a "challenge" (i suspect
I was not rigorous with it) that went with it, so I had: HMAC(HASH(password),
challenge), and that's what got sent across. Since the server had the original
HASH(password) and the challenge it could verify that you knew the password
without either the hash or password being sent. I know for a fact that I
wasn't handling replay of the challenge properly but it wouldn't be too
difficult to deal with it (add the time and have it expire after so long). But
I definitely had other problems with it (no SSL, and probably bad sidechannel
issues).

~~~
hvidgaard
Yes! You're the first in this thread that sounds like you have put actual
throught into security and threat modeling.

~~~
tripzilch
If we talk about "hash the password before sending to the server" this
procedure is what we're talking about (or something similar). Surely people
aren't thinking of literally just hashing the password and sending it on its
merry way? If we say "symmetric encryption" we don't mean we're going to do
AES(block_n, key) either (ECB mode should never be used for anything).

------
sbuttgereit
From Appendix A of 800-63B:

 _" Research has shown, however, that users respond in very predictable ways
to the requirements imposed by composition rules."_

I'm not disputing this statement, but there is no reference to the supporting
research either. I get that this isn't an academic paper, but I'd be curious
to see the research they're referring to nonetheless. Does anyone here happen
to know what they may have relied on for that claim?

~~~
asperous
[http://www.guanotronic.com/~serge/papers/chi11b.pdf](http://www.guanotronic.com/~serge/papers/chi11b.pdf)

~~~
sbuttgereit
Very cool, many thanks!

------
kondro
Can someone suggest a federated protocol for password changing so my password
manager can rotate passwords on my behalf in breaches and just every month or
so?

~~~
Elepsis
I wrote two blog posts on this idea a few years ago, but alas no credible
player has pursued documenting a standard protocol for this. Password managers
are, probably pragmatically, writing custom scrapers for major sites instead.

------
jarboot
_As correctly captured by Peter Steiner in The New Yorker, “On the internet,
nobody knows you’re a dog.”_

Interesting to see a cartoon cited in a government publication.

~~~
DenisM
You will be most pleased to know that the CIA made a reference to a Woodie
Allen movie making mockery of the CIA.

I can hardly wait till Woody Allen makes a reference to that publication in
one of his upcoming movies.

[https://www.cia.gov/library/center-for-the-study-of-
intellig...](https://www.cia.gov/library/center-for-the-study-of-
intelligence/csi-publications/csi-studies/studies/vol.-55-no.-4/driving-the-
yanquis-bananas-the-feeling-was-mutual.html)

------
known
Check [https://www.random.org/passwords/](https://www.random.org/passwords/)

------
laslfasjflsal
About Passwords - [https://sites.google.com/site/magyarinformatikus/about-
passw...](https://sites.google.com/site/magyarinformatikus/about-passwords)

