These are client secrets, not user passwords, so they’re supposed to be high entropy and not human-memorable (or human-typable really). Also, this needs to be used over TLS. The connection requires TLS anyway because the tokens returned (or the token keys in the OAuth PoP case) also need to be protected, regardless of how you hash the client’s secret. With that in mind, Digest doesn’t buy you much.
— Justin > On Jul 26, 2016, at 8:08 PM, Jim Manico <j...@manicode.com> wrote: > > Please forgive me if this comment is out of order or inappropriate in any > way... > > ...but why is HTTP Basic even being discussed in 2016? It has horrific > security properties at multiple levels; shouldn't we at least move to HTTP > Digest if not something stronger? > > Regards. > -- > Jim Manico > @Manicode > >> On Jul 26, 2016, at 4:48 PM, RFC Errata System <rfc-edi...@rfc-editor.org> >> wrote: >> >> The following errata report has been submitted for RFC6749, >> "The OAuth 2.0 Authorization Framework". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6749&eid=4749 >> >> -------------------------------------- >> Type: Technical >> Reported by: Phil Hunt <phil.h...@oracle.com> >> >> Section: 2.3.1 >> >> Original Text >> ------------- >> Clients in possession of a client password MAY use the HTTP Basic >> authentication scheme as defined in [RFC2617] to authenticate with >> the authorization server. The client identifier is encoded using the >> "application/x-www-form-urlencoded" encoding algorithm per >> Appendix B, and the encoded value is used as the username; the client >> password is encoded using the same algorithm and used as the >> password. The authorization server MUST support the HTTP Basic >> authentication scheme for authenticating clients that were issued a >> client password. >> >> Corrected Text >> -------------- >> Clients in possession of a client password MAY use the HTTP Basic >> authentication scheme as defined in [RFC2617] to authenticate with >> the authorization server. The client identifier is encoded using the >> "application/x-www-form-urlencoded" encoding algorithm per >> Appendix B, and the encoded value is used as the username; the client >> password is encoded using the same algorithm and used as the >> password. The url encoded values are then encoded as defined in >> [RFC2617]. The authorization server MUST support the HTTP Basic >> authentication scheme for authenticating clients that were issued a >> client password. >> >> Notes >> ----- >> It was not clear to some implementers that the intention is a 2-step >> encoding. First for special characters and second the 2617 base 64 encoding. >> Implementers thought 6749 was in conflict with 2617. >> >> To avoid inter-op issues, a new clarifying sentence is proposed. >> "The url encoded values are then encoded as defined in [RFC2617]." >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6749 (draft-ietf-oauth-v2-31) >> -------------------------------------- >> Title : The OAuth 2.0 Authorization Framework >> Publication Date : October 2012 >> Author(s) : D. Hardt, Ed. >> Category : PROPOSED STANDARD >> Source : Web Authorization Protocol >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
