> If it turns out to be true, > this could easily impact the vast majority of web applications written > in ASP.NET.
I read the detailed description of the vulnerability as well as the paper of work from Eurocrypt a few years back. This looks like the real deal in terms of a serious vulnerability. > There are a few workarounds. The first is to switch your server from > AES to 3DES. This is detailed in the link above. Based on what I read, the cipher has nothing at all to do with the vulnerability. The root problem is the way the .NET crypto API reports padding errors for CBC mode. Switching from CBC to another mode would likely be a better triage in general, but I'm not certain whether other modes are supported by the crypto API or the Forms authentication framework in particular. It's fully possible that the attack tool that's been released uses AES, but I'm not aware of anything AES-specific about this vulnerability in general. If you have a reference to anything AES-specific, please share it -- I may have missed something. > The second is CAS client specific and makes use of a feature of the > DotNetCasClient that effectively eliminates the attack vector.... When the CAS > client validates the FormsAuthenticationTicket, it checks that the CAS > service ticket matches a ticket retained on the server. If it doesn't, > the request is treated as anonymous and the cookie is destroyed. Are there any aspects of the cookie that are trusted, such as expiration? If not I think we're entirely safe. 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-user
