Provided by: libsession-storage-secure-perl_0.7-1_all 
NAME
Session::Storage::Secure - Encrypted, expiring, compressed, serialized session data with
integrity
VERSION
version 0.007
SYNOPSIS
my $store = Session::Storage::Secure->new(
secret_key => "your pass phrase here",
default_duration => 86400 * 7,
);
my $encoded = $store->encode( $data, $expires );
my $decoded = $store->decode( $encoded );
DESCRIPTION
This module implements a secure way to encode session data. It is primarily intended for
storing session data in browser cookies, but could be used with other backend storage
where security of stored session data is important.
Features include:
• Data serialization and compression using Sereal
• Data encryption using AES with a unique derived key per encoded session
• Enforced expiration timestamp (optional)
• Integrity protected with a message authentication code (MAC)
The storage protocol used in this module is based heavily on A Secure Cookie Protocol
<http://www.cse.msu.edu/~alexliu/publications/Cookie/Cookie_COMNET.pdf> by Alex Liu and
others. Liu proposes a session cookie value as follows:
user|expiration|E(data,k)|HMAC(user|expiration|data|ssl-key,k)
where
| denotes concatenation with a separator character
E(p,q) is a symmetric encryption of p with key q
HMAC(p,q) is a keyed message hash of p with key q
k is HMAC(user|expiration, sk)
sk is a secret key shared by all servers
ssl-key is an SSL session key
Because SSL session keys are not readily available (and SSL termination may happen prior
to the application server), we omit "ssl-key". This weakens protection against replay
attacks if an attacker can break the SSL session key and intercept messages.
Using "user" and "expiration" to generate the encryption and MAC keys was a method
proposed to ensure unique keys to defeat volume attacks against the secret key. Rather
than rely on those for uniqueness, which also reveals user name and prohibits anonymous
sessions, we replace "user" with a cryptographically-strong random salt value.
The original proposal also calculates a MAC based on unencrypted data. We instead
calculate the MAC based on the encrypted data. This avoids the extra step of decrypting
invalid messages. Because the salt is already encoded into the key, we omit it from the
MAC input.
Therefore, the session storage protocol used by this module is as follows:
salt|expiration|E(data,k)|HMAC(expiration|E(data,k),k)
where
| denotes concatenation with a separator character
E(p,q) is a symmetric encryption of p with key q
HMAC(p,q) is a keyed message hash of p with key q
k is HMAC(salt, sk)
sk is a secret key shared by all servers
The salt value is generated using Math::Random::ISAAC::XS, seeded from Crypt::URandom.
The HMAC algorithm is "hmac_sha256" from Digest::SHA. Encryption is done by Crypt::CBC
using Crypt::Rijndael (AES). The ciphertext and MAC's in the cookie are Base64 encoded by
MIME::Base64.
During session retrieval, if the MAC does not authenticate or if the expiration is set and
in the past, the session will be discarded.
ATTRIBUTES
secret_key (required)
This is used to secure the session data. The encryption and message authentication key is
derived from this using a one-way function. Changing it will invalidate all sessions.
default_duration
Number of seconds for which the session may be considered valid. If an expiration is not
provided to "encode", this is used instead to expire the session after a period of time.
It is unset by default, meaning that sessions expiration is not capped.
METHODS
encode
my $string = $store->encode( $data, $expires );
The $data argument should be a reference to a data structure. It must not contain
objects. If it is undefined, an empty hash reference will be encoded instead.
The optional $expires argument should be the session expiration time expressed as epoch
seconds. If the $expires time is in the past, the $data argument is cleared and an empty
hash reference is encoded and returned. If no $expires is given, then if the
"default_duration" attribute is set, it will be used to calculate an expiration time.
The method returns a string that securely encodes the session data. All binary components
are base64 encoded.
An exception is thrown on any errors.
decode
my $data = $store->decode( $string );
The $string argument must be the output of "encode".
If the message integrity check fails or if expiration exists and is in the past, the
method returns undef or an empty list (depending on context).
An exception is thrown on any errors.
LIMITATIONS
Secret key
You must protect the secret key, of course. Rekeying periodically would improve security.
Rekeying also invalidates all existing sessions. In a multi-node application, all nodes
must share the same secret key.
Session size
If storing the encoded session in a cookie, keep in mind that cookies must fit within 4k,
so don't store too much data. This module uses Sereal for serialization and enables the
"snappy" compression option. Sereal plus Snappy appears to be one of the fastest and most
compact serialization options for Perl, according to the Sereal benchmarks
<https://github.com/Sereal/Sereal/wiki/Sereal-Comparison-Graphs> page.
However, nothing prevents the encoded output from exceeding 4k. Applications must check
for this condition and handle it appropriately with an error or by splitting the value
across multiple cookies.
Objects not stored
Session data may not include objects. Sereal is configured to die if objects are
encountered because object serialization/deserialiation can have undesirable side effects.
Applications should take steps to deflate/inflate objects before storing them in session
data.
SECURITY
Storing encrypted session data within a browser cookie avoids latency and overhead of
backend session storage, but has several additional security considerations.
Transport security
If using cookies to store session data, an attacker could intercept cookies and replay
them to impersonate a valid user regardless of encryption. SSL encryption of the
transport channel is strongly recommended.
Cookie replay
Because all session state is maintained in the session cookie, an attacker or malicious
user could replay an old cookie to return to a previous state. Cookie-based sessions
should not be used for recording incremental steps in a transaction or to record "negative
rights".
Because cookie expiration happens on the client-side, an attacker or malicious user could
replay a cookie after its scheduled expiration date. It is strongly recommended to set
"cookie_duration" or "default_duration" to limit the window of opportunity for such replay
attacks.
Session authentication
A compromised secret key could be used to construct valid messages appearing to be from
any user. Applications should take extra steps in their use of session data to ensure
that sessions are authenticated to the user.
One simple approach could be to store a hash of the user's hashed password in the session
on login and to verify it on each request.
# on login
my $hashed_pw = bcrypt( $password, $salt );
if ( $hashed_pw eq $hashed_pw_from_db ) {
session user => $user;
session auth => bcrypt( $hashed_pw, $salt ) );
}
# on each request
if ( bcrypt( $hashed_pw_from_db, $salt ) ne session("auth") ) {
context->destroy_session;
}
The downside of this is that if there is a read-only attack against the database (SQL
injection or leaked backup dump) and the secret key is compromised, then an attacker can
forge a cookie to impersonate any user.
A more secure approach suggested by Stephen Murdoch in Hardened Stateless Session Cookies
<http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf> is to store an iterated
hash of the hashed password in the database and use the hashed password itself within the
session.
# on login
my $hashed_pw = bcrypt( $password, $salt );
if ( bcrypt( $hashed_pw, $salt ) eq $double_hashed_pw_from_db ) {
session user => $user;
session auth => $hashed_pw;
}
# on each request
if ( $double_hashed_pw_from_db ne bcrypt( session("auth"), $salt ) ) {
context->destroy_session;
}
This latter approach means that even a compromise of the secret key and the database
contents can't be used to impersonate a user because doing so would requiring reversing a
one-way hash to determine the correct authenticator to put into the forged cookie.
Both methods require an additional database read per request. This diminishes some of the
scalability benefits of storing session data in a cookie, but the read could be cached and
there is still no database write needed to store session data.
SEE ALSO
Papers on secure cookies and cookie session storage:
• Liu, Alex X., et al., A Secure Cookie Protocol
<http://www.cse.msu.edu/~alexliu/publications/Cookie/Cookie_COMNET.pdf>
• Murdoch, Stephen J., Hardened Stateless Session Cookies
<http://www.cl.cam.ac.uk/~sjm217/papers/protocols08cookies.pdf>
• Fu, Kevin, et al., Dos and Don'ts of Client Authentication on the Web
<http://pdos.csail.mit.edu/papers/webauth:sec10.pdf>
CPAN modules implementing cookie session storage:
• Catalyst::Plugin::CookiedSession -- encryption only
• Dancer::Session::Cookie -- Dancer 1, encryption only
• Dancer::SessionFactory::Cookie -- Dancer 2, forthcoming, based on this module
• HTTP::CryptoCookie -- encryption only
• Mojolicious::Sessions -- MAC only
• Plack::Middleware::Session::Cookie -- MAC only
• Plack::Middleware::Session::SerializedCookie -- really just a framework and you
provide the guts with callbacks
Related CPAN modules that offer frameworks for serializing and encrypting data, but
without features relevant for sessions like expiration and unique keying.
• Crypt::Util
• Data::Serializer
SUPPORT
Bugs / Feature Requests
Please report any bugs or feature requests through the issue tracker at
https://github.com/dagolden/session-storage-secure/issues
<https://github.com/dagolden/session-storage-secure/issues>. You will be notified
automatically of any progress on your issue.
Source Code
This is open source software. The code repository is available for public review and
contribution under the terms of the license.
https://github.com/dagolden/session-storage-secure <https://github.com/dagolden/session-
storage-secure>
git clone git://github.com/dagolden/session-storage-secure.git
AUTHOR
David Golden <dagolden@cpan.org>
COPYRIGHT AND LICENSE
This software is Copyright (c) 2013 by David Golden.
This is free software, licensed under:
The Apache License, Version 2.0, January 2004