Subject: [OAUTH-WG] Example tokens

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Jul 2011 15:40:01 -0700

Are the tokens used in the examples long enough? I don't want the examples to demonstrate poor choice of byte count.

EHL

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Jul 2011 17:06:29 -0600

If I've done the math correctly, 27 characters would give you a little
more than 20 bytes worth of randomness (assuming your are using random
alphanumeric characters or base64url encoded bytes).  20 bytes is
something you see as a SHOULD type minimum length in other protocols
for random identifiers.  Not sure if that's sufficient reasoning but
it's what I can come up with.

On Wed, Jul 6, 2011 at 4:40 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Are the tokens used in the examples long enough? I don't want the examples
> to demonstrate poor choice of byte count.
> EHL
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Oleg Gryb <[email-masked]>
Date: Wed, 6 Jul 2011 16:27:14 -0700 (PDT)

log2(64^27)=162 bits

Looks good. For comparison, 128-bit entropy for a key in symmetric encryption 
used by SSL is considered as strong.
I'm assuming that all those 162 bits are generated by a good randomizer.

----- Original Message ----
> From: Brian Campbell <[email-masked]>
> To: Eran Hammer-Lahav <[email-masked]>
> Cc: OAuth WG <[email-masked]>
> Sent: Wed, July 6, 2011 4:06:29 PM
> Subject: Re: [OAUTH-WG] Example tokens
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Jul 2011 21:45:51 -0600

So on the 128-bit note, the examples could probably be a bit shorter,
22 characters would give somewhat more than 128 bits of randomness.
But to EHL's original question, the examples (currently 7-12
characters) should probably be longer.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Jul 2011 20:53:58 -0700

Does that apply to access tokens, refresh tokens, and authorization codes? I can try squeezing in 22 characters.

EHL

> -----Original Message-----
> From: Brian Campbell [mailto:[email-masked]]
> Sent: Wednesday, July 06, 2011 8:46 PM
> To: Oleg Gryb
> Cc: Eran Hammer-Lahav; OAuth WG
> > Looks good. For comparison, 128-bit entropy for a key in symmetric
> > encryption used by SSL is considered as strong.
> >> If I've done the math correctly, 27 characters would give you a
> >> little more  than 20 bytes worth of randomness (assuming your are
> >> using  random alphanumeric characters or base64url encoded bytes).
> >> 20 bytes  is something you see as a SHOULD type minimum length in
> >> other  protocols for random identifiers.  Not sure if that's
> >> sufficient  reasoning but it's what I can come up with.
> >>
> >> On Wed, Jul 6, 2011 at  4:40 PM, Eran Hammer-Lahav
> >> <[email-masked]>
> > wrote:

---

From: Brian Campbell <[email-masked]>
Date: Wed, 6 Jul 2011 22:02:38 -0600

Yes, I think it would apply to all three (in cases where the value is
some reference).  I feel like a refresh token should be a little
longer but I don't know if that feeling would actually hold up when
doing a real threat model analysis.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 7 Jul 2011 14:10:57 +1000

No.

I found the following example values in draft 16.

Client secret: gX1fBat3bV              (10 chars,  60 bits)

Code:          i1WsRn1uB1              (10 chars,  60 bits)
Access token:  SlAV32hkKG              (10 chars,  60 bits)
Access token:  FJQbwq9                 ( 7 chars,  48 bits)
Access token:  7Fjfp0ZBr1KtDRbnfVdmIw  (22 chars, 132 bits, bearer token)
Access token:  h480djs93hd8            (12 chars,  72 bits, MAC id)
Refresh token: 8xLOxBtZp8              (10 chars,  60 bits)
Refresh token: n4E9O119d               ( 9 chars,  54 bits)
User password: A3ddj3w                 ( 7 chars,   ? bits, user-chosen)
 
128 bits of entropy would be a good choice for most values. That is
equivalent to 22 random base64 chars, as per longest example above. That is
a minimum mentioned in draft-lodderstedt-oauth-security. Using 22-char
values throughout the spec probably doesn't harm readability much as most of
the examples already wrap over multiple lines (it might even help by
wrapping more parameter names to the start of lines).
 
The example user password is long enough.
 
Curiously the secrets, codes, and tokens all look like base64-encoded values
- but almost none are actually valid base64 (the last char leaves non-zero
bits in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw
(last char changes) to be a base64-encoding of 7 bytes.
 
I suggest using four 22-char values for the four quantities (client secret,
code, access token, refresh token) consistently throughout the spec. Here
are four:
 
  2YotnFZFEjr1zCsicMWpAA
  tGzv3JOkF0XG5Qx2TlKWIA
  7Fjfp0ZBr1KtDRbnfVdmIw
  SplxlOBeZQQYbYS6WxSbIA

--

James Manger

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 6 Jul 2011 21:57:59 -0700

Fantastic!

From: Manger, James H [mailto:[email-masked]]
Sent: Wednesday, July 06, 2011 9:11 PM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Example tokens

No.

128 bits of entropy would be a good choice for most values. That is equivalent to 22 random base64 chars, as per longest example above. That is a minimum mentioned in draft-lodderstedt-oauth-security. Using 22-char values throughout the spec probably doesn't harm readability much as most of the examples already wrap over multiple lines (it might even help by wrapping more parameter names to the start of lines).

Curiously the secrets, codes, and tokens all look like base64-encoded values - but almost none are actually valid base64 (the last char leaves non-zero bits in a final partial byte). For instance, i1WsRn1uB1 should be i1WsRn1uBw (last char changes) to be a base64-encoding of 7 bytes.

I suggest using four 22-char values for the four quantities (client secret, code, access token, refresh token) consistently throughout the spec. Here are four:

  2YotnFZFEjr1zCsicMWpAA

  tGzv3JOkF0XG5Qx2TlKWIA

  7Fjfp0ZBr1KtDRbnfVdmIw

  SplxlOBeZQQYbYS6WxSbIA

--
James Manger

---

From: "William J. Mills" <[email-masked]>
Date: Thu, 7 Jul 2011 06:24:55 -0700 (PDT)

Access tokens realistically may be longer as they may have encrypted scopes and such.

________________________________
From: Eran Hammer-Lahav <[email-masked]>
To: Brian Campbell <[email-masked]>; Oleg Gryb <[email-masked]>
Cc: OAuth WG <[email-masked]>
Sent: Wednesday, July 6, 2011 8:53 PM
Subject: Re: [OAUTH-WG] Example tokens

EHL

---

From: George Fletcher <[email-masked]>
Date: Thu, 07 Jul 2011 09:34:32 -0400

+1

If the system just needs a random identifier with state maintained on 
the server, then the current tokens are fine. For those systems that 
plan to encrypt data in the scopes (or use JWTs) they will be much larger.

Thanks,
George

On 7/7/11 9:24 AM, William J. Mills wrote:
> ------------------------------------------------------------------------
> *From:* Eran Hammer-Lahav <[email-masked]>
> *To:* Brian Campbell <[email-masked]>; Oleg Gryb 
> <[email-masked]>
> *Cc:* OAuth WG <[email-masked]>
> *Sent:* Wednesday, July 6, 2011 8:53 PM
> *Subject:* Re: [OAUTH-WG] Example tokens
>
> Does that apply to access tokens, refresh tokens, and authorization 
> codes? I can try squeezing in 22 characters.
>
> EHL
>
> > From: Brian Campbell [mailto:[email-masked] 
> <mailto:[email-masked]>]
> > On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > > log2(64^27)=162 bits
> > >
> > >> From: Brian Campbell <[email-masked] 
> <mailto:[email-masked]>>
> > >> To: Eran Hammer-Lahav <[email-masked] 
> <mailto:[email-masked]>>
> > >> Cc: OAuth WG <[email-masked] <mailto:[email-masked]>>
> > >> <[email-masked] <mailto:[email-masked]>>
> > > wrote:
> > >> > [email-masked] <mailto:[email-masked]>
> > >> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 07:25:35 -0700

That's not the point. Developers who are going to self-encode tokens don't need the examples.

EHL

From: George Fletcher [mailto:[email-masked]]
Sent: Thursday, July 07, 2011 6:35 AM
To: William J. Mills
Cc: Eran Hammer-Lahav; Brian Campbell; Oleg Gryb; OAuth WG
Subject: Re: [OAUTH-WG] Example tokens

+1

If the system just needs a random identifier with state maintained on the server, then the current tokens are fine. For those systems that plan to encrypt data in the scopes (or use JWTs) they will be much larger.

Thanks,
George

________________________________
From: Eran Hammer-Lahav <[email-masked]><mailto:[email-masked]>
To: Brian Campbell <[email-masked]><mailto:[email-masked]>; Oleg Gryb <[email-masked]><mailto:[email-masked]>
Cc: OAuth WG <[email-masked]><mailto:[email-masked]>
Sent: Wednesday, July 6, 2011 8:53 PM
Subject: Re: [OAUTH-WG] Example tokens

EHL

> From: Brian Campbell [mailto:[email-masked]<mailto:[email-masked]>]
> On Wed, Jul 6, 2011 at 5:27 PM, Oleg Gryb <[email-masked]<mailto:[email-masked]>> wrote:
> > log2(64^27)=162 bits
> >
> >> From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
> >> To: Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
> >> Cc: OAuth WG <[email-masked]<mailto:[email-masked]>>
> >> <[email-masked]<mailto:[email-masked]>>
> > wrote:
> >> > [email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

OAuth mailing list

[email-masked]<mailto:[email-masked]>