Fourth Announcement for ECC 2003

--- begin forwarded text Status: U Date: Fri, 13 Jun 2003 18:05:10 -0400 (EDT) From: ECC 2003 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Fourth Announcement for ECC 2003 - THE 7TH WORKSHOP ON ELLIPTIC CURVE CRYPTOGRAPH

Re: An attack on paypal

On Fri, Jun 13, 2003 at 04:32:12PM -0700, Bill Stewart wrote: > An e-gold-specific or paypal-specific client can tell, > because it can remember that it's trying to see the real thing, > but the browser can't tell, except by bugging you about > "Hi, this is a new site that's giving us a new cert" p

RE: Keyservers and Spam

At 03:41 PM 6/13/03 -0700, Bill Frantz wrote: > >The HighFire project at Cryptorights > is planning on building a >"web of trust" rooted in the NGOs who will be using the system. Each NGO >will have a signing key. A NGO will sign the keys of the peo

Re: Session Fixation Vulnerability in Web Based Apps

-- On 14 Jun 2003 at 19:07, Rich Salz wrote: > When I've done login and state management, it's all > maintained on the server side. It's completely independant > of SSL sessions -- that's transport, has no place in > application -- just like it's completely independant of > HTTP/1.1 sessio

Re: Session Fixation Vulnerability in Web Based Apps

> The framework, however, generally provides insecure cookies. No I'm confused. First you said it doesn't make things like the session-ID available, and I posted a URL to show otherwise. Now you're saying it's available but insecure? /r$ -- Rich Salz Chief Security Archi

Re: Session Fixation Vulnerability in Web Based Apps

On Sun, Jun 15, 2003 at 11:34:55AM -0700, James A. Donald wrote: > Which is fine provided your code, rather than the framework > code provided the cookie, and provided you generated the cookie > in response to a valid login, as Ben Laurie does.. The > framework, however, generally provides insec

Re: Session Fixation Vulnerability in Web Based Apps

I think he means higher level frameworks, web programming libraries, toolkits, and web page builder stuff; not hooks into SSL sessions. Not to say that a hook into an SSL session is not a good place to get an application sessions identifier from -- it would be, presuming that you can't trick a brow