From: Baruch E. <ba...@ev...> - 2001-10-11 20:30:55
|
* Ian Bicking <ia...@co...> [011011 22:23]: > Geoff Talvola <gta...@na...> wrote: > > That reminds me of something I meant to bring up a while ago. Session IDs > > are currently not very random. Only the last 5 digits are actually random > > -- the rest of it is just the current time expressed as a string. > > > > This could be a security hole in that it makes it not too hard to guess the > > session ID and take over a session. > > Well, if you also used IP number in the session, you'd make it much > more secure. Potentially a malicious snoop could intercept the HTTP > requests and get the cookie, no matter how random. But it's > considerably more difficult to get the cookie and impersonate or > intercept the IP address. > > Simply guessing the session ID wouldn't provide anything, either, > since again it's quite hard to fake an IP address effectively. If someone can sniff out your session, he can easily fake the TCP/IP connection with ease. I wrote something about trying to secure HTTP sessions, it all boils down to the fact that if the attacker can sniff your connection, the only chance is SSL, anything else can be overcome. If the attacher cannot sniff your connection than making sure the SessionID is hard to guess will suffice, just MD5/SHA1 a large enough blob of random data and you should be fine. Note, I'm not a security expert or anything, just someone with enough interest in the topics of Cryptography and Computer Security. The said article can be found at http://baruch.ev-en.org/writings/WebAuthentication.html It includes a buildup of the ideas and is hopefully in a clear enough language. -- Baruch Even http://baruch.ev-en.org/ |
From: <pa...@bo...> - 2001-10-16 09:19:54
|
Baruch Even <ba...@ev...> wrote: > >* Ian Bicking <ia...@co...> [011012 00:06]: >> 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. I once worked on an application where a secure login solution without SSL was required. It was decided that a Java applet should be employed to do the appropriate password encryption/hashing (I can't remember the details now), although this obviously meant that users needed to have Java enabled; this was something that we could do, however, since the user community was a captive audience. The whole non-SSL requirement originated from French government restrictions on encryption which were subsequently removed, although given the cross-border nature of the organisation in question and the need for encryption principally existing only amongst Internet-based users (as opposed to intranet-based users), I'm sure some more inventive methods could have been used to employ any encryption services in Switzerland... Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su |
From: Ian B. <ia...@co...> - 2001-10-11 21:16:21
|
Baruch Even <ba...@ev...> 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? 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. 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. 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...? Ian |
From: Baruch E. <ba...@ev...> - 2001-10-13 15:24:57
|
* Ian Bicking <ia...@co...> [011012 00:06]: > Baruch Even <ba...@ev...> 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/ |