Peter Gutmann wrote:
> Jerry Leichter 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-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 pass
Jerry Leichter 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 - rea
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
t
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 encryp
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
manne
Thai Duong wrote:
> On Tue, Sep 28, 2010 at 12:49 PM, Peter Gutmann
> 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 u
On 2010-09-28 1:58 PM, Thai Duong wrote:
On Sat, Sep 18, 2010 at 8:43 PM, Peter Gutmann
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? �Interesting, I thought they
had th
On Tue, Sep 28, 2010 at 12:49 PM, Peter Gutmann
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 badly in other places. Down
On Sat, Sep 18, 2010 at 8:43 PM, Peter Gutmann
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? Interesting, I thought they
> had that one right, at least.
We promised
Peter Gutmann wrote:
> Tom Ritter 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 FormsAuthen
On Wed, Sep 15, 2010 at 11:07 AM, Peter Gutmann
wrote:
> Tom Ritter 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
Tom Ritter 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 cookie-based au
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 beca
=JeffH quotes:
>"We knew ASP.NET was vulnerable to our attack several months ago, but we
>didn't know how serious it is until a couple of weeks ago. It turns out that
>the vulnerability in ASP.NET is the most critical amongst other frameworks.
>In short, it totally destroys ASP.NET security," sai
On Tue, 14 Sep 2010 23:14:36 +1200 Peter Gutmann
wrote:
> The earlier work is also pretty devastating against CAPTCHAs (as
> well as being a damn good read, "Sudo make me a CAPTCHA" :-). A
> great many CAPTCHAs work by using a hidden form field containing
> the encrypted solution to the CAPTCHA,
practical "Padding Oracle Attacks" (cf travis' msg "padding attack vs. PKCS7"
of Thu, 11 Jun 2009 11:37:16 -0500)...
'Padding Oracle' Crypto Attack Affects Millions of ASP.NET Apps
<http://threatpost.com/en_us/blogs/new-crypto-attack-affects-millions
Here's what happens when you get your integrity checks wrong
Begin forwarded message:
> From: priv...@vortex.com
> Date: September 13, 2010 1:26:10 PM EDT
> To: privacy-l...@vortex.com
> Subject: [ PRIVACY Forum ] 'Padding Oracle' Crypto Attack Affects Millions of
18 matches
Mail list logo
