Hash ticket strings to generate valid-length session-ids.

[adamfranco]

By using a sha256 hash of the ticket, the session-id is guaranteed to be
64 bytes long no matter how short or long the ticket provided by the CAS
server is.

This fixes #248, fixes #244, and partially addresses the comments in #224 with the
exception of an extra salt or random-seed when generating the hash.

[adamfranco]

@jfritschi Let me know if you'd like to integrate this fix as-is in this PR or would prefer to add a additional configuration for a salt/seed for the hash. My only hesitancy with that is that it further pollutes the API even as we're thinking of cleaning it up. I'll submit a separate PR with this change plus the configurable salt/seed.

[jfritschi]

The reason I would like at least the option to include a user configured seed is hardening of the session token.
With the simple hash solution we artificially increase the length of the token without including real entropy. In a sense we are undermining the new and improved php session security standards that demand a long and random session string. Also the CAS tokens were never aimed at longer term usage. They are usually limited to a few minutes which means a small size is acceptable since any brute force is only doable in a short interval. This is not really true for a website session which may last hours or even days....
By having a seed option we allow the user to manually increase security. In my view we need it needs to be a random value set by the user (or a pseudo random but static value which however may have some issues in multi system setups). This seeding could be part of our optional hardening recommendations.

Your thoughts?

[jfritschi]

Sorry did not see the other pull before. I really think we should go for the other pull request that includes the salt.

[jfritschi]

Sorry did not see the other pull before. I really think we should go for the other pull request that includes the salt.