Re: Password identifiers, protocol aging and SCRAM protocol

A few couple more things that caught my eye while hacking on this:

1. We don't use SASLPrep to scrub username's and passwords. That's by
choice, for usernames, because historically in PostgreSQL usernames can
be stored in any encoding, but SASLPrep assumes UTF-8. We dodge that by
passing an empty username in the authentication exchange anyway, because
we always use the username we got from the startup packet. But for
passwords, I think we need to fix that. The spec is very clear on that:

> Note that implementations MUST either implement SASLprep or disallow
> use of non US-ASCII Unicode codepoints in "str".

2. I think we should check nonces, etc. more carefully, to not contain
invalid characters. For example, in the server, we use the
read_attr_value() function to read the client's nonce. Per the spec, the
nonce should consist of ASCII printable characters, but we will accept
anything except the comma. That's no trouble to the server, but let's be
strict.

To summarize, here's the overall TODO list so far:

* Use SASLPrep for passwords.

* Check nonces, etc. to not contain invalid characters.

* Derive mock SCRAM verifier for non-existent users deterministically
from username.

* Allow plain 'password' authentication for users with a SCRAM verifier
in rolpassword.

* Throw an error if an "authorization identity" is given. ATM, we just
ignore it, but seems better to reject the attempt than do something that
might not be what the client expects.

* Add "scram-sha-256" prefix to SCRAM verifiers stored in
pg_authid.rolpassword.

Anything else I'm missing?

I've created a wiki page, mostly to host that TODO list, while we hack
this to completion:
https://wiki.postgresql.org/wiki/SCRAM_authentication. Feel free to add
stuff that comes to mind, and remove stuff as you push patches to the
branch on github.

- Heikki