Transcripts of the NIST Sessions from the first SHA3 Candidate Conference
The transcripts are available at: http://csrc.nist.gov/groups/ST/hash/sha-3/Round1/Feb2009/program.html saqib http://www.capital-punishment.us - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
More man-in-the-middle'd SSL sessions on the way
From an article about WAN optimization appliances in Computerworld: In some markets, such as health and finance, [hiring] a managed provider [who will do the encryption "outside" your routers] isn't a good option for another reason: Because data is optimized in an unencrypted state, privacy and security concerns arise. But vendors such as Riverbed, Juniper Networks and Blue Coat Systems can serve as a trusted "man in the middle" for optimizing data encrypted with SSL, which is commonly used in applications with Web interfaces and other Internet traffic. They terminate the encrypted session, decrypt, optimize and then re-encrypt and forward the traffic. [Gartner's Joe] Skorupa said most vendors are developing this useful capability. It may indeed be a useful capability - but widespread use will destroy what little is left of the SSL trust model. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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, who just implemented something like this for one of his clients -- Derek Atkins 617-623-3745 [EMAIL PROTECTED] www.ihtfp.com Computer and Internet Security Consultant - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 just plain won't work. I think I understand this, but I'm not sure if it matters. It matters because IP addresses are now longer assigned to computers. Up until the mid-to-late 90s, your approach would have "worked" although it would not have been very secure. Perhaps it would have helped some, as you suggest. The point is that, since IP spoofing is difficult (at least, considerably MORE difficult than stealing a session key), you could be fairly sure you were cutting out an awful lot of hacker attacks. This is your logical error. IP spoofing is not difficult and it is not rare. It is a constant part of any NAT (network address translation) system. It is used everywhere by proxies. You may have hundreds or even thousands of individual computers masked behind a proxy, all with the same IP address. The second problem is that many ISPs, especially AOL, change the IP address during a session. We learned this the hard way back in 97 at CyberCash, when we tried the same idea. 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. Pat Pat Farrell [EMAIL PROTECTED] http://www.pfarrell.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 with you on the phone upset that he can't log in to his bank account, especially since the problem will be very difficult for anyone involved to diagnose or explain. Multiply that by tens of thousands of calls, and you're talking about real money. Failures like that are a large fraction of banking costs. Part of the point of on-line banking for banks is to raise margins, so if you piss all the money away on support costs and many people can't use the system you're sunk. > So ... if you find that you can't log in from work (or anywhere you > may have distributed proxies), tough. A large fraction, if not the majority, of users are currently behind proxies and NATs. I doubt it would be possible to block them on that basis without it being financially ruinous. In any case, given the various spoofing methods available, authenticating based on IP address seems rather weak, though I don't see why a cookie couldn't be tied to an address just to raise the bar a little if it didn't stop use for proxied/NATed users. FYI, I would strongly suggest reading the original paper on session ID fixation/theft -- it goes over a number of ways that IDs can be mishandled and a number of possible coping strategies. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 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 not a question of whether it's secure or not, in any kind of environment > with distributed proxies, it just plain won't work. 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, and that the emphasis should be on preventing false positives (hackers). So ... if you find that you can't log in from work (or anywhere you may have distributed proxies), tough. Just try again when you get home, where there are no distributed proxies in the way. If you believe that security is more important than convenience, is this not reasonable? The point is that, since IP spoofing is difficult (at least, considerably MORE difficult than stealing a session key), you could be fairly sure you were cutting out an awful lot of hacker attacks. I freely admit that I don't understand all the issues here, but this does seem pretty straightforward. What am I missing? Jill - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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 learning fast, and I still think the following question is worth my asking (and someone answering) because I'm actually thinking of using this idea on a real web site. At the very least, it seems to me that it ought to be more secure than NOT tracking the IP. > 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 > session variable (so it's stored at the server end - the client just gets a > 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? Jill > [Moderator's Note: you might want to read the original paper again. It I didn't receive the rest of this moderator's note so I don't know what it was going to say. My apologies for not having changed the subject line from "RE: Session Fixation Vulnerability in Web Based Apps", and for not making it clear that this is a different and unrelated thread. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
