Cookie authentication and SHA-1 Support

153 views
Skip to first unread message

Will Sargent

unread,
Feb 24, 2017, 11:36:01 AM2/24/17
to play-fram...@googlegroups.com
Hi all,

As half the internet seems to be aware, there was a SHA-1 collision found by Google yesterday:


As Play uses SHA-1 internally, it's worth noting that there is no vulnerability in Play from this.  Play uses SHA-1 for authenticating cookies, but it does so in an HMAC construction, which is not directly vulnerable to a collision.  To break a SHA-1 HMAC, you need a second preimage attack, which has not been found yet.

However, attacks always get better, and SHA-1 is clearly looking insecure in the long term.  SHA-1 is already deprecated when used for cryptographic signatures in X.509 certificates, and the history of cryptographic algorithms is clear:


Added to that is the unfortunate reality that many companies don't care about the distinction between SHA-1 used as a digest, and SHA-1 used in a MAC -- to them, the mention of SHA-1 in itself is problematic when used in a security context.

There is another cryptographic hashing algorithm, Blake2b, which is known to be very fast, comes with a built in keyed mode for MAC, and has received very good reviews from the security community.  I've put together a pull request using blake2b as the default algorithm for cookie authentication:


There are advantages and disadvantages here.  First the advantages:

* blake2b is faster than SHA-1, so this will reduce CPU cycles spent on every request with a session cookie.
* blake2b is well reviewed, so this should be good for the next decade or so.
* There is still the option to use the SHA-1 HMAC for session cookie handling.

Disadvantages:

* Seamless migration is trickier, because upgraded servers won't validate with the same algorithm.  It could be possible to add a fallback or backport blake2b to 2.5.x.
* There are some applications which fake cookies and MACs as part of testing, and may not have access to a blake2b implemention
* The blake2b digest is longer than the SHA-1 digest, leaving less room for content inside the session cookie (max cookie size is about 4k).
* Corporations may not be familiar with blake2b at all or know how to categorize it.

Overall, I think there's a fairly good case for moving to blake2b in Play 2.6.x, but I'd like to get feedback from the community as well.  How much work is it in your organization to move from one MAC to another?  Any technical constraints I haven't thought of?

--
Will Sargent
Engineer, Lightbend, Inc.

Ben McCann

unread,
Feb 24, 2017, 1:33:57 PM2/24/17
to Will Sargent, play-fram...@googlegroups.com
I think we would need to figure out a migration path. E.g. only write new cookies with blake2b, but read cookies with both sha-1 and blake2b

-Ben


--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

James Roper

unread,
Feb 24, 2017, 6:19:53 PM2/24/17
to Ben McCann, Will Sargent, play-fram...@googlegroups.com
If we're going to do a change like this, we should use the opportunity to also switch to JWT.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Rich Dougherty

unread,
Feb 26, 2017, 1:25:57 PM2/26/17
to James Roper, Ben McCann, Will Sargent, play-fram...@googlegroups.com
I agree with Ben about the approach of supporting reading both formats for a while, especially if there's not an immediate security issue. If we move to JWT then we can detect that for this migration. JWT would also make future algorithm migrations easier because it encodes information about the algorithm in its header.
--
Rich Dougherty
Engineer, Lightbend, Inc

Dominik Dorn

unread,
Feb 26, 2017, 2:23:02 PM2/26/17
to Rich Dougherty, James Roper, Ben McCann, Will Sargent, play-fram...@googlegroups.com
+10 on JWT! This would make integrating with other microservices (on the same domain) (in possible different languages) much easier. 

--
Rich Dougherty
Engineer, Lightbend, Inc

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Will Sargent

unread,
Feb 26, 2017, 2:33:59 PM2/26/17
to Play framework dev, ri...@rd.gen.nz, ja...@lightbend.com, b...@benmccann.com, will.s...@lightbend.com
I think JWT is great, but moving away from a cookie based approach does mean than anything that looks at cookie data on the client side (i.e. the average SPA application) would have to change their internal code.  In the wild session cookies are used for storing all kinds of things, not just authentication.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Rich Dougherty
Engineer, Lightbend, Inc

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Dominik Dorn

unread,
Feb 26, 2017, 2:45:47 PM2/26/17
to Will Sargent, Play framework dev, Rich Dougherty, James Roper, Ben McCann, Will Sargent
hmm... Not sure, but at least in my applications, client side code (e.g. Javascript) is not supposed to fiddle with Play's session.
Even if it can read some values out of the session, it cannot validate those values as its missing the secret used to sign them.
Everything else (like apps can create/read their cookies) would stay the same. We'd probably even have to put the JWT into a cookie to make sure its sent with every request to the server
and not just hand-crafted ajax requests. 

Will Sargent

unread,
Feb 26, 2017, 8:56:07 PM2/26/17
to Dominik Dorn, Will Sargent, Play framework dev, Rich Dougherty, James Roper, Ben McCann
> Not sure, but at least in my applications, client side code (e.g. Javascript) is not supposed to fiddle with Play's session. 

Client side applications can't write to the session cookie, but they can still read any amount of values that have been placed in there.  As the session cookie is signed and has out of the box support, it's a natural grabbag for session state.

--
Will Sargent
Engineer, Lightbend, Inc.


James Roper

unread,
Feb 27, 2017, 1:22:13 AM2/27/17
to Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, will.s...@lightbend.com, b...@benmccann.com
It would still be cookie based, you'd just use JWT to encode/decode the PLAY_SESSION cookie, rather than URL encode it like we're currently doing.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
Rich Dougherty
Engineer, Lightbend, Inc

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Will Sargent

unread,
Feb 27, 2017, 11:17:06 AM2/27/17
to James Roper, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
So like header based JWT, but in the session cookie as well as in the Authorization header?

--
Will Sargent
Engineer, Lightbend, Inc.


Will Sargent

unread,
Feb 27, 2017, 11:42:47 AM2/27/17
to James Roper, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
So poking at this a bit more -- there is a JWT library for Play:


The interesting bit of the JWT library is that it exposes the session as a JsValue, giving more structure to the session cookie.

However, JWT does not have Blake2 on the list of algorithms -- the closest is HMAC using SHA-256.


JWT does allow for encryption, though, which I know has been brought up in regards to session cookies.


--
Will Sargent
Engineer, Lightbend, Inc.


Dominik Dorn

unread,
Feb 27, 2017, 3:50:44 PM2/27/17
to Will Sargent, James Roper, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
its like 

String cookieValue = JWT.encode(myMap, myKey);
response().setCookie("PLAY_SESSION", cookieValue); 



To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Dominik Dorn

unread,
Feb 27, 2017, 3:57:33 PM2/27/17
to Will Sargent, James Roper, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
I'm not really sure why we need to go with Blake2? Whats wrong with going with the algorithm that all the JWT implementations support already?
E.g. https://jwt.io/ supports "HS256" (which is probably HMAC with SHA-256) and "RS256" (not sure whats that)..

The other question (imho) really is "do we need to change it" ? Yes, google managed to make a collision, but it took them a looooooong time. So if we instead
would just introduce a timestamp for the session cookie (like we had in play 1) that was significantly lower than the time it takes to get a collision, we're still on the safe side for
the next couple years. 



To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Will Sargent

unread,
Feb 27, 2017, 4:02:51 PM2/27/17
to Dominik Dorn, James Roper, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
We don't need to go with Blake2 specifically -- but it is time to stop using SHA-1.  The lag on changing algorithms is such that you want to get started years in advance, because by the time they prove it in practice, it's too late to redo all the applications already out there.

Using JWT would be an advantage just in having a richer session API.  It would still have the problem in migration in that if you swap from SHA1-HMAC, the migration in existing applications isn't seemless and would have to be managed.



--
Will Sargent
Engineer, Lightbend, Inc.


Dominik Dorn

unread,
Feb 27, 2017, 5:04:14 PM2/27/17
to Will Sargent, James Roper, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
Using JWT would be an advantage just in having a richer session API.  It would still have the problem in migration in that if you swap from SHA1-HMAC, the migration in existing applications isn't seemless and would have to be managed.
Its not just a richer session API. It's a client side key-value store with cryptographic signatures, that has support in various languages and various frameworks.
You could reuse the same JWT token for another microservice thats written e.g. in Node or Ruby e.g. in a multi-subdomain microservice architecture. 
Like having one microservice ("auth") issuing the token and all the other ones (play, spray, node, ruby) just validating that the JWT hasn't been tampered with.

The only thing we need to do is make maybe the next few versions of the play-framework be able to "read" the old sessions and (more or less transparently) replace them with "new" ones. I had the same thing to do when I recently migrated away from the Play 2.5 crypto API .. I inspect the cookie value, decide which version it is and decode it with the corresponding strategy. New cookies only get issued with the new strategy, old ones get migrated. Then phase out the old cookie-signing thing into a library, so people that would still need to use it in x years can continue to use it if they wish. 

The thing about being ahead of time is true, but still, we're talking about session cookies. the average lifespan of those is hours, some might have days or months, but thats usually it. In most cases its cheaper to buy the company hosting the webapp you're trying to crack than to use the computer power (and $$$) to crack the cookie and make a collision. 

At the end, its not my decision and I hope nobody feels offended by me jumping in on this topic. I just really like to see native support for JWT in Play, as it would make integration with some legacy microservices I have (e.g. in PHP :( ) a lot easier. 

Cheers,
Dominik

James Roper

unread,
Feb 28, 2017, 1:15:36 AM2/28/17
to Dominik Dorn, Will Sargent, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
I think the biggest motivation for moving away from SHA1 for sessions is no practical reason, since as you point out, there will be no practical exploits against it for the next few years. The biggest motivation is purely marketing. "SHA1 is bad because Google broke it, Play uses SHA1, so Play must be bad" - that is the (completely flawed) logic that people will use when they find out that Play uses SHA1 for signing cookies. The people that say this have no understanding of the vulnerabilities, of what SHA1 is, of how HMAC influences it, but since Google says we shouldn't use it, and "Google is smarter than everyone", they will not be reasoned with. Then there will be security policies that have blanket statements saying SHA1 must not be used for anything, at all, full stop, no questions (don't tell them git uses it).

It doesn't matter that JWT doesn't support Blake2, because it does encode what algorithm is used in the token, which means we can trivially switch and be backwards compatible in future when JWT does support it.

As Dominik said, the JWT token would only be put in the cookie, exactly the same way that our current cookies are put in the cookie, it wouldn't be put in any other header.
--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

Christian Kaps

unread,
Feb 28, 2017, 3:10:29 AM2/28/17
to Play framework dev, b...@benmccann.com, will.s...@lightbend.com
It makes absolutely sense and I currently migrate all the Silhouette authenticators to use JWT instead of using a custom encoding scheme. The JWT format is well proven and widely accepted and it has built in all the needed features like singing and encryption. There exists also some high quality implementations for the JVM like https://github.com/auth0/java-jwt or https://bitbucket.org/b_c/jose4j/wiki/Home. A complete list can be found on the jwt.io website under the point "Libraries": https://jwt.io/
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Greg Methvin

unread,
Feb 28, 2017, 5:15:19 AM2/28/17
to James Roper, Dominik Dorn, Will Sargent, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
On Mon, Feb 27, 2017 at 10:15 PM, James Roper <ja...@lightbend.com> wrote:
I think the biggest motivation for moving away from SHA1 for sessions is no practical reason, since as you point out, there will be no practical exploits against it for the next few years. The biggest motivation is purely marketing. "SHA1 is bad because Google broke it, Play uses SHA1, so Play must be bad" - that is the (completely flawed) logic that people will use when they find out that Play uses SHA1 for signing cookies. The people that say this have no understanding of the vulnerabilities, of what SHA1 is, of how HMAC influences it, but since Google says we shouldn't use it, and "Google is smarter than everyone", they will not be reasoned with. Then there will be security policies that have blanket statements saying SHA1 must not be used for anything, at all, full stop, no questions (don't tell them git uses it).

Right. We're doing it now for political reasons essentially.


It doesn't matter that JWT doesn't support Blake2, because it does encode what algorithm is used in the token, which means we can trivially switch and be backwards compatible in future when JWT does support it.

This is a significant benefit. I also agree with Dominik that using JWT would really help interoperability with software built on other development stacks.
 

As Dominik said, the JWT token would only be put in the cookie, exactly the same way that our current cookies are put in the cookie, it wouldn't be put in any other header.

On 28 February 2017 at 07:03, Dominik Dorn <dom...@dominikdorn.com> wrote:
Using JWT would be an advantage just in having a richer session API.  It would still have the problem in migration in that if you swap from SHA1-HMAC, the migration in existing applications isn't seemless and would have to be managed.
Its not just a richer session API. It's a client side key-value store with cryptographic signatures, that has support in various languages and various frameworks.
You could reuse the same JWT token for another microservice thats written e.g. in Node or Ruby e.g. in a multi-subdomain microservice architecture. 
Like having one microservice ("auth") issuing the token and all the other ones (play, spray, node, ruby) just validating that the JWT hasn't been tampered with.

The only thing we need to do is make maybe the next few versions of the play-framework be able to "read" the old sessions and (more or less transparently) replace them with "new" ones. I had the same thing to do when I recently migrated away from the Play 2.5 crypto API .. I inspect the cookie value, decide which version it is and decode it with the corresponding strategy. New cookies only get issued with the new strategy, old ones get migrated. Then phase out the old cookie-signing thing into a library, so people that would still need to use it in x years can continue to use it if they wish. 

The thing about being ahead of time is true, but still, we're talking about session cookies. the average lifespan of those is hours, some might have days or months, but thats usually it. In most cases its cheaper to buy the company hosting the webapp you're trying to crack than to use the computer power (and $$$) to crack the cookie and make a collision. 

At the end, its not my decision and I hope nobody feels offended by me jumping in on this topic. I just really like to see native support for JWT in Play, as it would make integration with some legacy microservices I have (e.g. in PHP :( ) a lot easier. 

Cheers,
Dominik




--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Greg Methvin
Tech Lead - Play Framework

Christian Schmitt

unread,
Feb 28, 2017, 8:57:52 AM2/28/17
to Play framework dev, ja...@lightbend.com, dom...@dominikdorn.com, will.s...@lightbend.com, will.s...@typesafe.com, ri...@rd.gen.nz, b...@benmccann.com
I like the JWT idea.
However I think for Crypto we should just use the built into java thing HMAC SHA512 or HMAC SHA256:

val mac = Mac.getInstance("HmacSHA512")
mac.init(new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), "HmacSHA512")) mac.doFinal(msg.getBytes(StandardCharsets.UTF_8))

This is also super suitable for JWT.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Xuefeng Wu

unread,
Feb 28, 2017, 10:53:53 PM2/28/17
to James Roper, Dominik Dorn, Will Sargent, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
@James
I agreed with you that most people doesn't understand what's the SHA1 problem. 
But the market is influenced by the google news. 


Play is a excellent framework meet the market, 

right now, the market is influenced by a news. 

I think the best way is meet the market, enhance the security (even not actually needed)
In other way, more security without much cost, is a good technology selection.


--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

~Yours, Xuefeng Wu/吴雪峰  敬上

James Roper

unread,
Mar 5, 2017, 8:44:19 PM3/5/17
to Xuefeng Wu, Dominik Dorn, Will Sargent, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com, Ben McCann
On 1 March 2017 at 14:53, Xuefeng Wu <ben...@gmail.com> wrote:
@James
I agreed with you that most people doesn't understand what's the SHA1 problem. 
But the market is influenced by the google news. 


Play is a excellent framework meet the market, 

right now, the market is influenced by a news. 

I think the best way is meet the market, enhance the security (even not actually needed)
In other way, more security without much cost, is a good technology selection.

Yes, that's exactly my thinking.
 


On Tue, Feb 28, 2017 at 2:15 PM, James Roper <ja...@lightbend.com> wrote:
I think the biggest motivation for moving away from SHA1 for sessions is no practical reason, since as you point out, there will be no practical exploits against it for the next few years. The biggest motivation is purely marketing. "SHA1 is bad because Google broke it, Play uses SHA1, so Play must be bad" - that is the (completely flawed) logic that people will use when they find out that Play uses SHA1 for signing cookies. The people that say this have no understanding of the vulnerabilities, of what SHA1 is, of how HMAC influences it, but since Google says we shouldn't use it, and "Google is smarter than everyone", they will not be reasoned with. Then there will be security policies that have blanket statements saying SHA1 must not be used for anything, at all, full stop, no questions (don't tell them git uses it).

It doesn't matter that JWT doesn't support Blake2, because it does encode what algorithm is used in the token, which means we can trivially switch and be backwards compatible in future when JWT does support it.

As Dominik said, the JWT token would only be put in the cookie, exactly the same way that our current cookies are put in the cookie, it wouldn't be put in any other header.

On 28 February 2017 at 07:03, Dominik Dorn <dom...@dominikdorn.com> wrote:
Using JWT would be an advantage just in having a richer session API.  It would still have the problem in migration in that if you swap from SHA1-HMAC, the migration in existing applications isn't seemless and would have to be managed.
Its not just a richer session API. It's a client side key-value store with cryptographic signatures, that has support in various languages and various frameworks.
You could reuse the same JWT token for another microservice thats written e.g. in Node or Ruby e.g. in a multi-subdomain microservice architecture. 
Like having one microservice ("auth") issuing the token and all the other ones (play, spray, node, ruby) just validating that the JWT hasn't been tampered with.

The only thing we need to do is make maybe the next few versions of the play-framework be able to "read" the old sessions and (more or less transparently) replace them with "new" ones. I had the same thing to do when I recently migrated away from the Play 2.5 crypto API .. I inspect the cookie value, decide which version it is and decode it with the corresponding strategy. New cookies only get issued with the new strategy, old ones get migrated. Then phase out the old cookie-signing thing into a library, so people that would still need to use it in x years can continue to use it if they wish. 

The thing about being ahead of time is true, but still, we're talking about session cookies. the average lifespan of those is hours, some might have days or months, but thats usually it. In most cases its cheaper to buy the company hosting the webapp you're trying to crack than to use the computer power (and $$$) to crack the cookie and make a collision. 

At the end, its not my decision and I hope nobody feels offended by me jumping in on this topic. I just really like to see native support for JWT in Play, as it would make integration with some legacy microservices I have (e.g. in PHP :( ) a lot easier. 

Cheers,
Dominik




--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

~Yours, Xuefeng Wu/吴雪峰  敬上

Ben McCann

unread,
Mar 14, 2017, 4:11:25 PM3/14/17
to James Roper, Xuefeng Wu, Dominik Dorn, Will Sargent, Will Sargent, Rich Dougherty, play-fram...@googlegroups.com
There was a post about JWT on HN this morning: https://news.ycombinator.com/item?id=13865459


The problem with JWT/JOSE is that it's too complicated for what it does. It's a meta-standard capturing basically all of cryptography which, as you've ably observed (along with Matthew Green), was not written by or with cryptographers. Crypto vulnerabilities usually occur in the joinery of a protocol. JWT was written to maximize the amount of joinery.

Good modern crypto constructions don't do complicated negotiation or algorithm selection. Look at Trevor Perrin's Noise protocol, which is the transport for Signal. Noise is instantiated statically with specific algorithms. If you're talking to a Chapoly Noise implementation, you cannot with a header convince it to switch to AES-GCM, let alone "alg:none". The ability to negotiate different ciphers dynamically is an own-goal. The ability to negotiate to no crypto, or (almost worse) to inferior crypto, is disqualifying.

A good security protocol has good defaults. But JWT doesn't even get non-replayability right; it's implicit, and there's more than one way to do it. Application data is mixed with metadata (any attribute not in the JOSE header is in the same namespace as the application's data). Anything that can possibly go wrong, JWT wants to make sure will go wrong.

It's 2017 and they still managed to drag all of X.509 into the thing, and they indirect through URLs. Some day some serverside library will implement JWK URL indirection, and we'll have managed to reconstitute an old inexplicably bad XML attack.

For that matter, something crypto people understand that I don't think the JWT people do: public key crypto isn't better than symmetric key crypto. It's certainly not a good default: if you don't absolutely need public key constructions, you shouldn't use them. They're multiplicatively more complex and dangerous than symmetric key constructions. But just in this thread someone pointed out a library --- auth0's --- that apparently defaults to public key JWT. That's because JWT practically begs you to find an excuse to use public key crypto.

These words occur in a JWT tutorial (I think, but am not sure, it's auth0's):

"For this reason encrypted JWTs are sometimes nested: an encrypted JWT serves as the container for a signed JWT. This way you get the benefits of both."

There are implementations that default to compressed.

There's a reason crypto people table flip instead of writing detailed critiques of this protocol. It's a bad protocol. You look at this and think, for what? To avoid the effort of encrypting a JSON blob with libsodium and base64ing the output? Burn it with fire.



To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

Matthias Kurz

unread,
Mar 15, 2017, 3:50:54 AM3/15/17
to Play framework dev, ja...@lightbend.com, ben...@gmail.com, dom...@dominikdorn.com, will.s...@lightbend.com, will.s...@typesafe.com, ri...@rd.gen.nz
Ben, Will already had a look at the article, check out his answer:

--
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

~Yours, Xuefeng Wu/吴雪峰  敬上




--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

Will Sargent

unread,
Mar 15, 2017, 8:39:14 AM3/15/17
to Matthias Kurz, Play framework dev, ben...@gmail.com, dom...@dominikdorn.com, ja...@lightbend.com, ri...@rd.gen.nz, will.s...@typesafe.com
I do think they could have done much better defining the RFC, but there's much less to this than you'd think.  All this article says is that it doesn't stop people from picking the wrong cryptographic options, or using JWT in a way that could be insecure.  I think Jacob Ideskog has some good things to say on that, but that's neither here nor there.

Play has good defaults, will verify the signature algorithm and uses a library with no encryption available, and is using cookies just as the article says to do.

We've been telling people to use libsodium for encryption in Play 2.5, have deprecated the Crypto object and have a sample project showing kalium use of a cookie baker on the download page.  I really don't know of anything more we could do except maybe more advertising.

Will.



--
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

~Yours, Xuefeng Wu/吴雪峰  敬上




--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--

Ben McCann

unread,
Mar 16, 2017, 8:26:02 PM3/16/17
to Will Sargent, Matthias Kurz, Play framework dev, ben...@gmail.com, Dominik Dorn, James Roper, Rich Dougherty, Will Sargent
Thanks for the pointer to the PR. Glad to see we're checking the incoming signature algorithm! It could be easy to overlook, but luckily it's something our users wouldn't have to worry about as the framework takes care of it

--
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

~Yours, Xuefeng Wu/吴雪峰  敬上




--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
--
Will Sargent
Engineer, Lightbend, Inc.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.

Christian Schmitt

unread,
Mar 17, 2017, 5:31:12 AM3/17/17
to Play framework dev, will.s...@lightbend.com, m.k...@irregular.at, ben...@gmail.com, dom...@dominikdorn.com, ja...@lightbend.com, ri...@rd.gen.nz, will.s...@typesafe.com
Well actually the first thing after I worked with JWT, is actually checking the signature algorithm. I think even if the RFC is not really good, JWT is completly fine.
I mean this particular user is extremly biased against JWT. But he actually says some should just use Cookies. (Actually he mostly talks bad about it when it comes to authentication/authorization).

I mean yes, the RFC/Specification of JWT is pretty broken, but most of his statements that he written are completly false or are actually a problem of every token based authorization.
At the current state of the web there is no 100% secure algorithm for such a thing, but as will already pointed out, we don't use JWT for anything that needs to stay highly secure, we just use it for Sessions. Which are in most cases not encrypted.

James Roper

unread,
Mar 19, 2017, 9:58:13 PM3/19/17
to Christian Schmitt, Play framework dev, Will Sargent, m.kurz, Xuefeng Wu, Dominik Dorn, Rich Dougherty, Will Sargent
On 17 March 2017 at 20:31, Christian Schmitt <c.sc...@briefdomain.de> wrote:
Well actually the first thing after I worked with JWT, is actually checking the signature algorithm. I think even if the RFC is not really good, JWT is completly fine.
I mean this particular user is extremly biased against JWT. But he actually says some should just use Cookies. (Actually he mostly talks bad about it when it comes to authentication/authorization).

I mean yes, the RFC/Specification of JWT is pretty broken, but most of his statements that he written are completly false or are actually a problem of every token based authorization.
At the current state of the web there is no 100% secure algorithm for such a thing, but as will already pointed out, we don't use JWT for anything that needs to stay highly secure, we just use it for Sessions. Which are in most cases not encrypted.

And it is always a compromise - the important thing is rather than bluntly enforcing security principles with no regard for the use cases involved, that users understand the technology they are using, what the limits are of it, and then apply it to their use case (or don't apply it if it's not suitable) accordingly.  The advantages of not just signed sessions, but signed tokens for authorization, to the resilience and scalability of a system, can be immense, I've been using json signed tokens since before JWT existed, and they played a huge part in building a system that was quite resilient to any of its parts going down.  The inability to immediately invalidate them is actually not quite true - you can do it with the right tools, eg using CRDTs, while still getting the resilience advantages that they offer, because replicating a very small list of revoked tokens among your front end servers can be done cheaply without impacting availability, while replicating the authorization data they enforce can't.  It's more complex to maintain a system like that, but that complexity is just part of the compromise.  In this case, a social network of 10 million active users, (this was studiVZ, which back then, was that active. of course it's dead now), that complexity was worth it to maintain the availability and scalability we needed.

--
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

~Yours, Xuefeng Wu/吴雪峰  敬上




--
James Roper
Software Engineer

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
--
--
Will Sargent
Engineer, Lightbend, Inc.

--
You received this message because you are subscribed to the Google Groups "Play framework dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.




--
Reply all
Reply to author
Forward
0 new messages