> conveying a cryptographic hash of > the password from the rendered Blackboard application login form in the > browser to the Blackboard server (as in, a hash instead of the actual > password). Then the server validates that the hash is valid.
You've just described a client-side HMAC implementation, if I understood correctly, which has no additional security value over a plaintext password assuming no further computation happens to the credential on the server other than comparison with a known value. In either case the value sent over the wire is sufficient alone to perform authentication. I suppose if this is an enterprise credential not having it stored in the clear on the client might have security value to _other_ applications. In that case, however, I'd argue that something is horribly wrong with your browser if it stores cleartext passwords. > I tend to advise against this kind of fanciness as beside the point. > Either > you trust SSL or you don't, and if you don't, the implications are > really bad in ways that a little hashing of passwords aren't going to fix. +1 > I can state from personal experience that this kind of thing > discourages (but doesn't completely prevent!) integration via credential > replay through the login form. I'm fairly confident that the present implementation of the LT parameter on the login form is sufficient to guard against replay attacks. I invite folks to play with 3.4.10 and see if they can demonstrate a reasonable replay attack. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
