Andrew, I recall seeing a production Blackboard environment a few years ago (maybe 8.x?) that used crazy, obfuscated JavaScript that in the end just Base64-encoded the password. The project manager at the time thought this obviated the need for SSL, until we cracked open a laptop, sniffed some traffic, and decoded a password in front of them. Ah, good times ;-)
The only value to client-side hashing or obfuscation that I can think of would be mitigating key loggers, cache file attacks, etc. Didn't Unicon implement something that used mouse clicks on a virtual keyboard for PIN entry, to avoid key logging malware? -Aaron --------------------------------- Aaron Fuleki Senior Web Architect Denison University 740.587.5752 --------------------------------- On Thu, Sep 29, 2011 at 1:15 PM, Andrew Petro <[email protected]> wrote: > I bet Thach meant in the browser. > > Blackboard [1], for instance, does this, 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. Actual > password doesn't appear in the traffic or browser history (?) which is > arguably incremental value over not engaging in these extra complex heroics. > > Agreed that CAS doesn't currently do this. It would probably require a > fancy AuthenticationHandler, or at least a fancy backing service behind the > AuthenticationHandler, to cope with validating the hash rather than the > plaintext. > > 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. > > However, 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. That it doesn't completely prevent is the > detail that jumps out to me -- in general I don't seek to annoy the > Adversary, I seek to block him completely. SSL in principle secures the > conveyance of password from browser to login form via HTTPS form POST. > Everything else is window dressing. IMHO. > > [1]: As in, I've seen some version of Blackboard with some configuration do > this at some point in my career. There's a chance that a few minutes of > looking at Blackboard login forms on the Web would turn up an example. It > made it extra difficult (but not impossible :) ) to accomplish credential > replay through the Blackboard login form on a project I was on once upon a > time. > > > > > On 09/29/2011 10:00 AM, Marvin Addison wrote: > >> I want to implement the CAS with feature the password is encrypt in client >>> side. >>> >> That's a very unusual requirement. Perhaps you could elaborate on >> your use case to clarify your requirements. >> >> Does the current CAS supports this feature? >>> >> No, and it's fundamentally impossible since the client never handles >> the user's password. The password is provided exclusively to the CAS >> server, and this is done in all by exceptional cases over SSL, as >> Andrew noted. If you mean another password other than that of the >> user, please clarify. Also, I've interpreted "client" as a CAS client >> application; if you mean something else, please clarify. >> >> 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<http://www.ja-sig.org/wiki/display/JSG/cas-dev> > -- 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
