[security] OpenID Security Best Practices Doc
Nate Klingenstein
ndk at internet2.edu
Tue Jun 9 05:16:37 UTC 2009
Allen,
> I guess tying the nonce to the browser's IP address would be
> sufficent, although if there's a MITM, the attacker presumably
> controls the IP address as well.
Shibboleth has offered similar matching of client IP address to
assertion and IP address to SP/RP session for a long time. We've
found the first impractical and the second pretty useful. Matching an
RP-installed authentication request nonce with an IP address would be
consistent with the consistentAddress functionality.
I would certainly describe it as easier to grab an assertion or
session cookie than hijack another machine's IP address.
Note that if the value of checkAddress is set to "false",
this has a slightly negative
impact on the security of the SP. This security feature
checks the user's IP address
at the SP and compares it with the IP address used at the
IdP. If they don't match, an error
is thrown. This rather strict security feature can cause
problems for users behind proxies
or for users with IPv6 addresses. Therefore, this setting is
deactivated per default.
To compensate the slightly reduced security the
consistentAddress feature is activated
in the default configuration.
The consistentAddress feature is available as of version 1.3c
for the <Sessions> element.
It defaults to true when not present and ensures that once a
session cookie is
issued to a client, any further use of that session cookie
must be from a client with the
same network address. This raises the bar for session
hijackers to the level of network
address spoofing, which may or may not be simple to do, but
is definitely harder than
stealing cookies and relies on a different set of attacking
skills.
On the other hand the consistentAddress may also cause
problems for users whose IP changes
during the session (e.g. for AOL users or for users behind
proxies
which have multiple IP addresses).
https://spaces.internet2.edu/display/SHIB/AddressChecking
It's a neat feature, so thanks Andrew,
Nate.
More information about the security
mailing list