* Ian Bicking <[EMAIL PROTECTED]> [011012 00:06]: > Baruch Even <[EMAIL PROTECTED]> wrote: > > If someone can sniff out your session, he can easily fake the TCP/IP > > connection with ease. > > Really? I understand how sniffing works (though with proxies there's > potentially other ways that cookies can be spied on), but I don't > really know how IP address are spoofed. Without control of the > routers, wouldn't the return traffic end up going to the right subnet > no matter what, and wouldn't the correct computer at least try to > respond, even if another computer tried too?
Return traffic will go back to the host, but if you fake an unused port, the real host will just barf. There are several methods to be able to sit in between the real host and the data stream, one could spoof ARP messages and be able to filter everything and many variations exists, so usually if you assume that the attacker can sniff, you'd better be prepared also to the case that he can fake TCP/IP connections. > I'm not entirely clear on how TCP/IP connections are made, though, so > I might be missing something there. MAC addresses have to come in > there somewhere too, if I remember correctly, but I've forgotten > where. MAC addresses come on the last segment between the last router and the real host, that's where ARP spoofing works. > After reading your article, a non-SSL solution occurred to me. You > can implement MD5 on the client through Javascript (see > http://pajhome.org.uk/crypt/md5/md5src.html), and it's not even a very > long bit of code. It should be easy to send the salt as a hidden > field in the form, then onSubmit do a bit of code to hash the password > with the salt and delete the plaintext password. It is a possibility, and I've used it on a site I built, but it depends on Javascript, which might not be enabled by default (I disable it on when I browse, unless I have to). And MD5 in Javascript can be slow, at least it was slow on the computers I needed it to run. > This only works with Javascript-enabled browsers, but that's most > people. Especially for privileged users, you can demand they use such > a browser (not a big deal). I'm not sure how to make sure the user > doesn't accidentally send their plaintext password when they don't > have Javascript, except to have a gateway page that uses the > Javascript code to preauthenticate in some manner. Though if you > don't name the password field, and use document.forms.someform[number] > to access it, then I suppose it's private to the browser...? You can use another variable on another form that will be submitted instead of the user viewed form, I've done this and if needed I can probably find the code and publish it. Baruch -- Baruch Even http://baruch.ev-en.org/ _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
