view release on metacpan or  search on metacpan

README  view on Meta::CPAN

included in the system (whether spanned by wildcard matches or server
side redirects).  No untrusted host should be in that set.  This is 
just classic host security.


Issue 3:  Secure Wildcard Cookies Don't Always Have Intended Protection

The underlying weakness in issue (2) is perhaps more relevant for so-called 
secure cookies (with secure flag is set).  Even where host security can be 
assumed across a large heterogeneous environment, there might be one
host which only supports 40-bit SSL, say hopkins.acme.org again.  Supposed 
bruce and wendel were properly configured for only 128-bit cipher suites 
and issued only secure cookies for the .acme.com domain.  Then a malicious 
image tag <img src="https://hopkins.acme.com"> will force a connection
to hopkins.  If 40-bit encryption is negotiated (see next issue), the user's
credentials are reduced from 128-bits to 40-bits.
   Unlike issue (2), we cannot pass this off as a matter of host security, 
because hopkins is not compromised.  A passive adversary who obtains
a 40-bit encrypted copy of the credentials.  He can then do an offline crack 
in order to assume the users identity.  Naively, bruce and wendel might
think an implausible work factor of 2^128 would be necessary.

SecSess.pm  view on Meta::CPAN

  
The QOP parameters are separated to allow flexibility in the threat model.
In the simplest paradigm (and first demo examples), qop=0 and authqop=40, 
which merely indicates that the user ID's and passwords are protected with 
SSL but the web docs acquired with them are not.  This is somewhat common 
over intranets.  Under the stronger threat model of an active adversary
who controls the untrusted network, true end-to-end security is 
required, but we may still wish to separate session and authentication 
qualities of protection.  For example, if all SSL sessions never drop
below 128-bits, we may still choose to allow weaker strength during user 
authentication, say with a 20-bit PIN or one-time password.  Scientific 
cryptography cannot always afford to distinguish between an attack which 
costs 2^20 computations and one which succeeds with probability 1/2^20, 
because with 1 million users, the two situations are identical.  But, for
practical risk assessment, it may be perfectly acceptable to trade strong
session credentials for weak login credentials.

The values of qop and authqop issued are determined by the
Apache::SecSess object in all cases.  For URL credentials they come
directly from arguments sessQOP and authQOP, respectively.  For cookie
credentials, they come from the hash keys of the argument cookieDomain

SecSess.pm  view on Meta::CPAN

If no cookies are present, the client will be redirected again to
https://stu.transacme.com/authen or the issue() method of a standard
Cookie-based login:

  <Location /authen>
    PerlAuthenHandler $Acme::stu->issue
    ...
  </Location>

where $Acme::stu is an instance of, say Apache::SecSess::Cookie::X509,
just as in the previous example.

But if and when cookies are present, $Acme::chain->issue will walk
through the URL's listed in the chainURLS argument eventually getting
to https://noam.acme.org/authen protected by

  <Location /authen>
    PerlAuthenHandler $Acme::noam->issue
    ...
  </Location>