On 29/07/16 06:09, Jim Manico wrote:
> Thank you Justin, comments inline.
>
>> These are client secrets, not user passwords, so they’re supposed to be high
>> entropy and not human-memorable (or human-typable really).
> This still sounds like sensitive data, and I don't understand the relevance
This is off topic for the errata process. This is not the place to propose a
re-write.
As one of the authors of the threat model and sec considerations I think we
covered this to too much. :-) Justin's comments are spot on.
This has nothing to do with user authentication.
Phil
> On Jul 28,
Thank you Justin, comments inline.
> These are client secrets, not user passwords, so they’re supposed to be high
> entropy and not human-memorable (or human-typable really).
This still sounds like sensitive data, and I don't understand the relevance of
"human memorable". If time allows can yo
PKCE256 becomes mandatory in that case. PKCE plain is prone to same attack as
that of state or none.
Also PKCE256 should generate new code challenge for every Authorization request.
-Vivek Biswas
Consulting Member@Security
Oracle.
From: ve7...@ve7jtb.com [mailto:ve7...@ve7jtb.com]
S
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 p
I’ve been thinking that we could, in some eventual rewrite of OAuth and its
kin, collapse the “state”, “nonce”, and “code_challenge” values all into a
single thing. They’re all serving similar purposes but being used differently.
There was even talk of replaying the “state” value at the token en
I congratulate the idea for a BCP.
Ideally that would be a document written with the developer in mind,
easy to consume, and outlining all necessary steps to take in order to
harden / patch up an OAuth 2.0 implementation / app. The individual
attacks could be referenced or described in an appendix
