> Did Unicon implement something that used mouse clicks on a virtual keyboard for PIN entry, to avoid key logging malware?
Yes. [1] iirc, that implementation sent the resulting PIN via a normal HTTPS form post -- that is, the nuance was in the UX for entry of the password, not in how the password was then conveyed to the CAS server for validation. > The only value to client-side hashing or obfuscation that I can think of would be mitigating key loggers, cache file attacks, etc. Yup. Depending on the details of the implementation and the attack characteristics one is trying to block, of course. A naive post-typing obfuscation doesn't do anything to block a keylogger trapping the actual keystrokes. But I take your meaning, Aaron -- I don't mean to stake out a blow-hard position that nothing is ever worth doing, and it may be that in consideration of some specific profile of an adversary adding some complexity could genuinely thwart, rather than merely inconvenience, the adversary. Andrew [1]: For a nuanced meaning of "yes". Unicon contributed substantively to that project, but the arrangement was to partner on the development rather than to wholesale outsource to Unicon the development. In the details, Unicon was hands-off regarding the actual PIN entry UX widget etc, Unicon's focus was more the architecture and implementing of chained CAS instances. More full disclosure than anyone may have cared about, I suppose. :) On 09/29/2011 10:43 AM, Aaron Fuleki wrote: > 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] > <mailto:[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] > <mailto:[email protected]> as: [email protected] > <mailto:[email protected]> > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > > -- > You are currently subscribed [email protected] > <mailto:[email protected]> as: [email protected] > To unsubscribe, change settings or access archives, see > 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
