Re: Sessions

Pat Farrell <[EMAIL PROTECTED]> writes: > The solution is not very hard, set a cookie with a strongly created > nonce, use that to index into the table of valid sessions. At least > it is easy until you want to scale it to many servers. This is what a backend database is for. ;) > Pat -derek, w

Re: Wildcard Certs

also sprach Stefan Kelm <[EMAIL PROTECTED]> [2003.06.16.1652 +0200]: > Now, suppose I buy a certificate for *.i-am-bad.com (assuming that I'm > the owner of that domain). I could then set up an SSL server with a > hostname of something like > > www.security-products.microsoft.com.order.regist

[mnet-devel] status of Mnet

--- begin forwarded text Status: U To: [EMAIL PROTECTED] From: Zooko <[EMAIL PROTECTED]> Subject: [mnet-devel] status of Mnet Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] List-Help: List-Post: List-Subscribe:

Re: Session Fixation Vulnerability in Web Based Apps

-- James A. Donald: > > 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 insecure > > cookies. Ng Pheng Siong

RE: Sessions

At 03:36 PM 6/16/2003 +0100, [EMAIL PROTECTED] wrote: > On Mon, Jun 16, 2003 at 10:47:04AM +0100, [EMAIL PROTECTED] wrote: > > session id). Authentication of subesequent pages is assumed only if the > > client's IP address matches the IP address stored in the session > with distributed proxies, it

Re: Sessions

[EMAIL PROTECTED] writes: > I think I understand this, but I'm not sure if it matters. It seems to me > that a false negative (failed login) is not particularly serious, Er, it is if you have to pay $5 or $10 in customer support fees dealing with the irate customer who spends half an hour or more

Re: Wildcard Certs

Martin, > Are wildcard certficates good? secure? useful? There's a problem with wildcard certs wrt how URLs are being displayed in many of the browsers, esp. the older ones. If the host name is extremely long the browser will be unable to show the complete URL to the user, with some browsers e

RE: Sessions

> From: Matthew Byng-Maddick [mailto:[EMAIL PROTECTED] > Sent: Monday, June 16, 2003 2:28 PM > To: [EMAIL PROTECTED] > Subject: Re: Session Fixation Vulnerability in Web Based Apps > > > On Mon, Jun 16, 2003 at 10:47:04AM +0100, [EMAIL PROTECTED] wrote: > > session id). Authentication of subeseq

Sessions

This has got nothing whatsoever to do with session fixation. It _has_ however, got something to do with security. In particular, with authentication. [Moderator's note: Actually, it seems to have everything to do with session fixation. --Perry] I may be ignorant about a few things but I'm learn

Re: Session Fixation Vulnerability in Web Based Apps

On Mon, Jun 16, 2003 at 10:47:04AM +0100, [EMAIL PROTECTED] wrote: > session id). Authentication of subesequent pages is assumed only if the > client's IP address matches the IP address stored in the session variable > corresponding to the client's session. > Is this secure? If not, why not? It's

RE: Session Fixation Vulnerability in Web Based Apps

I've come up with a (very simple) defence against session hijacking and so on. It's probably flawed (I admit I'm not an expert on these things), so if someone could please tell me why it won't work, I'd be very grateful. When the user logs in, the server stores the client's IP address in a sessio

Wildcard Certs

I just ran across http://certs.centurywebdesign.co.uk/premiumssl-wildcard.html but there are many more sites like that: Secure multiple websites with a single PremiumSSL Certificate. For organisations hosting a single domain name but with different subdomains (e.g. secure.centurywebdesig