Jerry Leichter leich...@lrw.com writes:
By the way, the don't acknowledge whether it was the login ID or the
password that was wrong example is one of those things everyone knows -
along with change your password frequently - that have long passed their
use by date.
You got there before I did
On 2010-10-02 (275), at 19:10, Jerry Leichter wrote:
On Oct 1, 2010, at 11:34 PM, Richard Outerbridge wrote:
[]
By the way, the don't acknowledge whether it was the login ID or
the password that was wrong example is one of those things
everyone knows - along with change your password
Peter Gutmann wrote:
Jerry Leichter leich...@lrw.com writes:
By the way, the don't acknowledge whether it was the login ID or the
password that was wrong example is one of those things everyone knows -
along with change your password frequently - that have long passed their
use by date.
On 2010-10-01 (274), at 12:29, Brad Hill wrote:
Kevin W. Wall wrote:
isn't the pre-shared key version of W3C's XML Encrypt also going to
be vulnerable
to a padding oracle attack.
Any implementation that returns distinguishable error conditions for
invalid
padding is vulnerable, XML
On Oct 1, 2010, at 11:34 PM, Richard Outerbridge wrote:
Any implementation that returns distinguishable error conditions
for invalid padding is vulnerable...
Oh come on. This is really just a sophisticated variant of the old
never say which was wrong - login ID or password - attack. In
Kevin W. Wall wrote:
isn't the pre-shared key version of W3C's XML Encrypt also going to be
vulnerable
to a padding oracle attack.
Any implementation that returns distinguishable error conditions for invalid
padding is vulnerable, XML encryption no more or less so if used in such a
manner.
On 2010-09-28 1:58 PM, Thai Duong wrote:
On Sat, Sep 18, 2010 at 8:43 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
I'm one of the authors of the attack. Actually if you look closer, you'll see
that they do it wrong in many ways.
The FormsAuth as well, not just the view state?
Thai Duong wrote:
On Tue, Sep 28, 2010 at 12:49 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Ye gods, how can you screw something that simple up that much? They use the
appropriate, and secure, HMAC-SHA1 and AES, but manage to apply it backwards!
I guess they just follow SSL.
On Tue, Sep 28, 2010 at 12:49 PM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Ye gods, how can you screw something that simple up that much? They use the
appropriate, and secure, HMAC-SHA1 and AES, but manage to apply it backwards!
I guess they just follow SSL.
BTW, they screw up more
On Wed, Sep 15, 2010 at 11:07 AM, Peter Gutmann
pgut...@cs.auckland.ac.nz wrote:
Tom Ritter t...@ritter.vg writes:
What's weird is I find confusing literature about what *is* the default for
protecting the viewstate.
I still haven't seen the paper/slides from the talk so it's a bit hard to
Peter Gutmann wrote:
Tom Ritter t...@ritter.vg writes:
What's weird is I find confusing literature about what *is* the default for
protecting the viewstate.
I still haven't seen the paper/slides from the talk so it's a bit hard to
comment on the specifics, but if you're using .NET's
Tom Ritter t...@ritter.vg writes:
What's weird is I find confusing literature about what *is* the default for
protecting the viewstate.
I still haven't seen the paper/slides from the talk so it's a bit hard to
comment on the specifics, but if you're using .NET's FormsAuthenticationTicket
(for
When their talk first started getting hyped on twitter last Thursday,
the focus was on ASP.Net's viewstate [1,2] rather than the cookie
aspect. (Viewstate is a base64 blob of data in a hidden form field
about the current state of controls on the page.) I wonder if
threatpost focused on cookies
13 matches
Mail list logo
