This blog post has some good background on why salting is no longer effective
against brute force attacks.
http://blog.ircmaxell.com/2011/08/rainbow-table-is-dead.html?m=1
More entropy in the secret is much more important.
The code verifier should not be thought of as a password. It needs t
Adding client ID is no better than simply adding extra random bits, but 256 is
a LOT.
Also remember that the server SHOULD:
- only allowing a code to be tried once- at a very minimum should have a
severely limited number of tries for a code- a short time window to use a
code
Unless you
Yes, "plain" is actually sufficient. The hashed value protects against
disclosure/logging threats on the server auth server and proxies perhaps where
the HTTPS is terminated somewhere other than the auth server itself, it's not
actually required for the basic functionality/security of the mecha
If an attacker can intercept and modify requests, they have complete control.
Trying to protect OAuth at that point is probably not practical. If you want
that then we need a confidential client with tpm storage of key material and
move to signed requests and responses.
That is possible but
2014/11/14 11:00、Nat Sakimura のメール：
> Regarding
>
> > Other problem is the following, using Nat’s slide:
> > http://www.slideshare.net/nat_sakimura/1112-spoppresso .
> >
> > 0.Attacker prepares own code_verifier and code_challenge.
> > 1.replage legitimate challenge with malicious co
Sorry for my poor english.
2014/11/14 10:55、Bill Mills のメール：
> The whole mechanism relies on the attacker not having access to the
> code_verifier or hash. It's defending against the attacker getting the code
> via weakness in IPC or other such mechanism like URI handlers. How many more
>
Hi all,
here is a draft version of the meeting minutes:
http://www.ietf.org/proceedings/91/minutes/minutes-91-oauth
Thanks to Brian Rosen for taking notes.
Comments are welcome!
Ciao
Hannes & Derek
signature.asc
Description: OpenPGP digital signature
_
Sorry for my poor english.
2014/11/14 10:45、John Bradley のメール：
> We have discussed it and that was in fact my original recommendation.
> However I have been convinced that it adds complexity without any real
> improvement in security.
Really?
I think that there is same discussion in stori
On Thu, Nov 13, 2014 at 6:00 PM, Nat Sakimura wrote:
> Regarding
>
> > Other problem is the following, using Nat’s slide:
> > http://www.slideshare.net/nat_sakimura/1112-spoppresso .
> >
> > 0.Attacker prepares own code_verifier and code_challenge.
> > 1.replage legitimate challenge with
There's a draft it would be great to get more eyes on in the Kitten WG
draft-ietf-kitten-sasl-oauth-17 - A set of SASL Mechanisms for OAuth
Nearing it's 5th and hopefully final WGLC, so any more eyes and comments on it
would be welcome.
Thanks,
-bill___
Regarding
> Other problem is the following, using Nat’s slide:
> http://www.slideshare.net/nat_sakimura/1112-spoppresso .
>
> 0.Attacker prepares own code_verifier and code_challenge.
> 1.replage legitimate challenge with malicious code_challenge.
> 5. Attacker can submits own code_verifie
The whole mechanism relies on the attacker not having access to the
code_verifier or hash. It's defending against the attacker getting the code
via weakness in IPC or other such mechanism like URI handlers. How many more
bits is secure beyond 256 bits of entropy recommended? If you want to ma
Changed milestone "Submit 'OAuth Dynamic Client Registration Protocol'
to the IESG for consideration as a Proposed Standard", resolved as
"Done".
URL: http://datatracker.ietf.org/wg/oauth/charter/
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.o
Changed milestone "Submit 'Proof-of-Possession OAuth Security'
document bundle for consideration as a Proposed Standard", set due
date to April 2015 from December 2014.
URL: http://datatracker.ietf.org/wg/oauth/charter/
___
OAuth mailing list
OAuth@ietf
We have discussed it and that was in fact my original recommendation. However
I have been convinced that it adds complexity without any real improvement in
security.
The reality is that people don't bother with rainbow tables these days. They
calculate hashes on the fly faster than they can
Changed milestone "Submit 'Proof-of-Possession OAuth Security'
document bundle for consideration as a Proposed Standard", set state
to active from review, accepting new milestone.
URL: http://datatracker.ietf.org/wg/oauth/charter/
___
OAuth mailing list
Hi all,
I appreciate this idea, simple and powerful to achieve proof of possession.
But, I have some questions against the scheme.
Sorry if these ware already discussed.
I worry about using a hash function in simple way.
I mean, a simple use of random as code_verifier may cause that malicious cl
I understand the intent of:
S256 "code_challenge" = BASE64URL(SHA256("code_verifier"))
but I think what it really says is take the base64url encoding of the sha256
hash of the constant string "code_verifier". Are those quotes really supposed
to be there?
-bill
This draft has crypto agility problems.
4.3 code_challenge_method default to 'plain' should be noted as supporting
legacy clients. This section should specify that S256 is MTI rather than
leaving it to 4.4.1.
I'd be much happier if this section said something like, "The server MUST
support a
I think you’re right, the text should probably “remainder of token omitted” for
the cases where it’s a non-JWT (and the key is passed from AS to RS in some
other fashion) or it should start like a regular JWT in that particular example.
— Justin
On Nov 13, 2014, at 12:58 AM, Antonio Sanso wro
hi *.
AFAIU the access token in the Client-to-AS Response is not “forced” to be JWT
format but can also be an opaque string.
Now the example rather says:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"access_token":"SlAV32hkKG ...
(remai
Hi
Very nice. Can it become drat-oauth-jwsreqres ?
I know spop-04 has been released, we'll update our implementation as
needed, but if an optional signing of a request is of interest, why
can't be signing of the response be of interest too ?
Thanks, Sergey
On 13/11/14 04:07, internet-dra...
22 matches
Mail list logo
