|Anders Rundgren||Jan 12, 2001 4:32 am|
|Paulus, Sachar||Jan 15, 2001 11:25 pm|
|Orchard, David||Jan 16, 2001 12:26 pm|
|Anders Rundgren||Jan 16, 2001 1:36 pm|
|Mishra, Prateek||Jan 16, 2001 1:56 pm|
|Anders Rundgren||Jan 16, 2001 10:08 pm|
|Orchard, David||Jan 16, 2001 10:33 pm|
|Orchard, David||Jan 16, 2001 10:44 pm|
|Anders Rundgren||Jan 17, 2001 5:21 am|
|Paulus, Sachar||Jan 17, 2001 7:16 am|
|Hal Lockhart||Jan 17, 2001 7:20 am|
|Anders Rundgren||Jan 17, 2001 7:31 am|
|Hal Lockhart||Jan 17, 2001 8:32 am|
|Subject:||Re: Web-browser Binding Vulnerabilities + "Cures"|
|From:||Anders Rundgren (ande...@telia.com)|
|Date:||Jan 16, 2001 1:36:41 pm|
David, I can't say I have tested a lot of browsers but so far as I know this method is used by Passport.com which is the SSO of Hotmail.com /Anders
----- Original Message ----- From: "Orchard, David" <dorc...@jamcracker.com> To: <"SMTP:sach"@sap.com' Sent: Tuesday, January 16, 2001 21:24 Subject: RE: Web-browser Binding Vulnerabilities + "Cures"
And how do you do cross domain cookies so that domain A can send info to Domain B? We haven't found many browsers that support this lack of cookie privacy.
Dave Orchard XML Architect Jamcracker Inc., 14000 Homestead Dr., Sunnyvale, CA 94086 p: 408.864.5118 f: 408.725.4310
Named to Red Herring's list of 100 Most Important Companies: www.redherring.com/mag/issue79/herring100/jamcracker.html
-----Original Message----- From: Paulus, Sachar [mailto:sach...@sap.com] Sent: Monday, January 15, 2001 11:25 PM To: 'Anders Rundgren'; S2ML Subject: RE: Web-browser Binding Vulnerabilities + "Cures"
That is what SAP experienced too. Therefore, our SSO solution uses (digitally signed user info in) cookies....
-----Original Message----- From: Anders Rundgren [mailto:ande...@telia.com] Sent: Freitag, 12. Januar 2001 13:30 To: S2ML Subject: Web-browser Binding Vulnerabilities + "Cures"
The following does IMO apply to many schemes including S2ML:
The use of references to assertions etc. in the form of URLs which are usually given to an authenticated client by a credential issuer using an HTTP 301 (redirect) has at least one problem: A credential consumer cannot easily determine if it is the original client that handed over the URL containing such a reference. A simple browser URL window snooper program could "snatch" such tokens and transport them to somebody else. In spite of secure https transports.
The only "cures" I can think of are putting the critical data in a cookie [sorry :-( ], which requires a fairly deep browser hack [open source would make it trivial though :-) ] to snatch, and IP bindings. The latter is not universal due to proxies (all clients on the same proxy looks like one IP for the credential consumer) etc. but it does improve the binding a bit.
Note: I don't insist that the current binding scheme should be changed, this is simply "information".