This is a secdir review of draft-ietf-httpauth-basicauth-update-06 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Overview ======== This draft updates the HTTP Basic Authentication scheme with a charset parameter, whose only allowed value is "UTF-8". I believe the draft is almost ready, but there are some issues, described below. Security and Privacy Considerations =================================== Should recommend strong password-hashing on the server side ----------------------------------------------------------- The Security Considerations section acknowledges that passwords can be stolen from servers, but does not encourage server operators to hash stored passwords with a reasonable or strong algorithm. This document may not be the place to provide normative guidance on how to store passwords to mitigate the exposure of a password table, but perhaps a brief mention and an informative reference would be useful? Many systems (e.g. modern nginx and apache) use 1000 iterations of salted MD5, but still support cleartext passwords, crypt(), and unsalted SHA-1, which are all terrible. https://httpd.apache.org/docs/2.4/misc/password_encryptions.html http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file an informative reference might point to the Password Hashing Competition, which documents sensible rationales for why you should use strong password hashing, and how to know it when you see it: https://password-hashing.net by comparison the digest draft has a lot more about how passwords should be stored (even though Digest auth can offer only weaker protections for the password store compared to Basic auth): https://tools.ietf.org/html/draft-ietf-httpauth-digest-13#section-5.2 Should recommend constant-time server-side comparisons ------------------------------------------------------ Servers that implement basic auth should not leak information about the stored password via timing of rejections. For example, a server that stored cleartext passwords (which is a bad idea anyway) should mechanically compare the entire string instead of bytewise comparisons. The attack here is an attacker who guesses credentials a byte at a time, by making 256 initial guesses and seeing which of them gets back a rejection faster than the other (and iterates down the list). This might be less of an issue for reasonable (non-cleartext) password storage, but if we're not requiring strong password hashing, we should at least require constant time comparisons. Should recommend padding the Authorization: response ---------------------------------------------------- When used behind HTTPS as recommended, TLS hides the username and password presented. However, it does not hide the length of the username and password if the other parameters of the HTTPS request are known. An active attacker who wants to learn the length of the victim's username and password together for a particular basic auth realm could force the user's browser to make HTTPS requests to a few different URLs within the realm and see how large the packets are. This could be mitigated by including whitespace padding in the client's Authorization: header itself up to some multiple of a blocksize (perhaps 256B) to obscure the length. UTF-8 security considerations by reference: is this OK? ------------------------------------------ The Security Considerations section includes the UTF-8 security considerations section by reference, but doesn't call out any specific issues for implementers to be aware of. the NFC canonicalization draft also has Security Considersations section, which is not included by reference: https://tools.ietf.org/html/rfc5198#section-6 Interaction with proxies? ------------------------- There is only a passing mention of Proxy-Authenticate: and Proxy-Authorization: headers, so one assumes that both mechanisms should support this new auth-param. It's not clear to me whether there are any additional security or privacy implications when this is addressed to proxies compared to origin servers. Section 2.2 ("reusing credentials") talks about the URI path (presumably for "WWW-Authenticate", but then mixes "Proxy-Authenticate" into the middle of that commentary. It looks to me like "Proxy-Authenticate" is not intended to be scoped by the URI path (there is no mention of "in that space" in the sentence about Proxy-Authenticate in Section 2.2), but this is kind of ambiguous. Clarification would be good. Path matching? -------------- Nothing in the security considerations section talks about the threat that motivates path matching for determination of which realm to use. It might be useful to spell this out explicitly: * A user agent that sends the Authorization: header to URLs outside the authentication scope as described in Section 2.2 may leak the user's credentials User Agent visibility and logout? --------------------------------- Most RFCs don't talk at all about the human interface of the mentioned tools. But this draft refers briefly to interaction between the user and the User Agent (see step 1 on https://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-06#page-6 ). However, it provides no other guidance. There are several additional guidelines that make basic authentication more acceptable from a privacy and security point of view for a typical web browser User Agent: * user agents should indicate to the user when they are re-using the user's authentication credentials as described in section 2.2 (indicating the realm, authentication scope, and user-id?) * user agents should not display the user's password anywhere by default * user agents should make it straightforward for users to clear their credentials for any . https://tools.ietf.org/html/rfc7235#section-6.3 includes some of these guidelines; perhaps this is another include-by-reference? Other Considerations ==================== Deployment chicken-and-egg -------------------------- The server has no way of knowing that the client is trying to obey the charset header. For the servers mentioned in that do user-agent sniffing, it's not clear how those servers could ever know to stop relying on the user-agent, since the clients have no way of signalling their intent to use UTF-8 for the Authorization header. If the servers don't know when to start accepting UTF-8 from these clients, then the clients also have no way of knowing when they should switch over themselves. This strikes me as a recipe for stalled adoption, since "user agents in the latter group" (from section B.3) will never use UTF-8, even if they know about it. If we want to avoid the adoption stall, we might need more forceful language to discourage user agents from trying to guess whether they are in "the latter group" User IDs with Colons -------------------- The draft says "a user-id containing a colon character is invalid" -- why not say that "the user-id MUST NOT contain a colon character", as it already does for control characters? Nits ==== * in B.3, "Authentication on these sites will stop to work" should be "Authentication on these sites will stop working" Regards, --dkg Attachment: signature.asc Description: PGP signature