Revision [1025]

This is an old revision of RalfLehmann made by RalfLehmann on 2004-08-18 21:49:37.

 

I have nothing special to say right now (except thank you for HideReferrers).

--Ralf Lehmann



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

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
There are no comments on this page.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki