You have to protect against three kinds of attacks (that is, attempts to
login without proper authentication in your main server):
1) forged cookies (plain text cookies are a snap to create)
2) tampered cookies (e.g., taking a valid cookie for "user=jones" and
changing it to "user=smith".
3) replayed cookies (e.g., "snooping" a cookie generated by a valid login
and re-using it later.
To protect against these attacks, your domain-wide cookie should have some
kind of authentication stamp. We do an MD5 hash of the username, a
timestamp, and a shared secret (shared by the servers that are 'in the club'
and no-one else). So our cookie* is created by the authentication server
as:
user=jones;time=999999999;MAC=7E848A98.....[more hex digits]
Where the "message authentication code" (MAC) is the MD5 hash referred to
above.
When the cookie is received by the wiki server, it is accepted only if:
1) the user, time, and shared secret, when hashed, give the same MAC
2) the timestamp is less than [some timeout number] seconds old.
This protects well against forged or tampered cookies, and protects somewhat
against replay attacks (protection is better when the timeout is shorter).
HTH,
-- Joshua
* In our case, it's not really a cookie, the information is passed in a
POST, but the principle is the same.
On 1/10/06 1:18 PM, "Domas Mituzas" <midom.lists(a)gmail.com> wrote:
Hi Justin,
So I guess my question is, should there be any
inherent problems
with trying
to assign the username using wiki's external authentication from a
cookie,
as opposed to REMOTE_USER or LDAP, etc?
On deployment for which I wrote this code we really use domain-wide
cookie instead of REMOTE_USER. Just make sure that user can't provide
invalid cookies.
Domas
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l