--Ralf Lehmann
Just a short note to DreckFehler: I will reply as soon as possible. ;) --RalfLehmann
Actually, I do have to say something now. :)
I was wondering if anybody else has thought about letting "the wiki" encrypt (MD5, of course) the password using javascript prior sending it (the password) to the server? I'm aware that this would require the client to have javascript enabled (doh!) and there are probably some issues I'm not yet aware of but there *might* be a smart solution that works for clients with/without javascript enabled... I haven't checked out each and every Wiki or CMS software (or you-name-it) yet to see how others handle it, though... ;)
edit: I'm not sure if this would really increase password's security in general. At least it wouldn't be sent unencrypted over the network anymore in case javascript is available...
it even is not safe when the password is encrypted. the md5 fingerprint fits perfectly in a cookie that is needed to gain access to your account. it's grave harder to catch this information than to exploit it ;). on the other hand the server will need additional information whether it has to deal with a straight password or with an md5 fingerprint to handle the login. if you need real security you must address this at a lower network layer. that is an ssl connection with which it is irrelevant whether the password is encrypted or not. -- DreckFehler
I absolutely agree on using SSL although it is not available in most environments where Wikis are used (mere assumption). As for the distinction between MD5/unencrypted password: Yes, this is what I meant when I was saying that "there *might* be a smart solution..." that fits both scenarios. I'm convinced that it is possible and since I'm the one who brought this up I will try to find a solution for this, just out of personal curiosity... ;) But again, when you happen to have a packet sniffer installed and just grab the packets from/to your IP address (which is the only reason I use something like that ;), it's pretty easy to find all kinds of passwords which are sent unencrypted (e-mail, login here, login there, etc. etc.). That's certainly not big news. The only reason I posted this here is that I think would be an advantage if web applications like Wikis, CMSes and so forth (which mostly require javascript anyway) could do something about sending passwords over the internet in an even more insecure manner than technically possible. I'm not sure if part of our discussion is based on a misunderstanding, though. ;) --RalfLehmann, 2004-08-18
.
> I'm convinced that it is possible and since I'm the one who brought this up I will try to find a solution for this, just out of personal curiosity... ;)
yep there are several. you have already stated only one that however seems to work fine. but that's not the point.
> But again, when you happen to have a packet sniffer installed
i do happen ;) and (assumed, we're connected to the same - insecure - network segment) as soon as i will get your md5-string, you'll never see your usersettings again (no, i'm only kidding!). since i really don't need your password to conquer your account it isn't worth the trouble to deal with a login encryption that only pretends security. i consider this pseudo-safety even more dangerous as it only lulls the users to sleep. at least it blows up the code without doing anything reasonable.
whereas the straight password only gets on the wire on rare occasions when you're logging in, the md5 fingerprint is always present in every request you are sending to the server. and with it (and your username of course) i can manually build a cookie without hassle which lets me drop in with your credentials - voila! again: if you're looking for a safe way you need to hide both the password itself and the md5-hash and that's what encryption at the network layer does. you can turn it over and over, you always will end up at this point. different protocol layers provide different functionality to solve different problems. it would be a broader step to more security than any other to change the cookie variable to another from all names than "password" and it's a step that is simple to do ;)
edit: Well well well, I should have read the entire page (2nd link below, "Anwendungsbeispiel") first. There's already a solution for the above mentioned problem regarding "server has to know whether the password is already encrypted or not". Pretty easy if you know how to do it: We will have two fields. One is for the user's input (password) and the other one is for the encrypted password (hidden). When the user clicks on "Send", the visible password field will be emptied if javascript is enabled. Now it's up to the server script to handle the incoming POST data (md5-encrypted password vs. "normal" password). What I wrote here is not exactly what has been mentioned there, just FYI. And to let the user know that we strongly suggest the usage of javascript, there could be some kind of eye-catching message next to the password input field which says "Be aware that if you log in without having javascript enabled, ... blah blah...". This warning could be hidden by javascript (if enabled/available) so it doesn't bother people who are using a js-enabled web client. Makes perfect sense to me... :o) --RalfLehmann, 2004-08-18
Just let me add two links to some javascripts (pretty easy to find by searching for "md5 javascript" ;):
http://pajhome.org.uk/crypt/md5/ (english page; BSD license)
http://aktuell.de.selfhtml.org/artikel/javascript/md5/ (german page; free for any purpose)
--RalfLehmann, 2004-08-17
CategoryUsers
