--
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.
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+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
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.
--
--
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.
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.
--
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
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.
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.
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--
--
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.
val mac = Mac.getInstance("HmacSHA512")
mac.init(new SecretKeySpec(secret.getBytes(StandardCharsets.UTF_8), "HmacSHA512"))
mac.doFinal(msg.getBytes(StandardCharsets.UTF_8))
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework-dev+unsub...@googlegroups.com.
--
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.
@JamesI 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.
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--
--
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/吴雪峰 敬上
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.
--
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/吴雪峰 敬上
--
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.
--
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.
--
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.
--
--
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.
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.
--
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.
--
--
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.