Revision history for RalfLehmann
Revision [23228]
Last edited on 2016-05-20 07:38:47 by JavaWoman [Replaces old-style internal links with new pipe-split links.]Additions:
--[[http://www.worldwidewiki.net/wiki/RalfLehmann | Ralf Lehmann]]
Deletions:
Revision [19209]
Edited on 2008-01-28 00:14:43 by JavaWoman [Modified links pointing to docs server]No Differences
Additions:
I have nothing special to say right now (except thank you for HideReferrers).
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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
----
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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
----
Deletions:
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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
----
Additions:
I have nothing special to say right now (except thank you for HideReferrers).
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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
----
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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
----
Deletions:
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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
----
Additions:
--RalfLehmann, 2004-08-17
CategoryUsers
CategoryUsers
Deletions:
Additions:
Just a short note to DreckFehler: I **will** reply as soon as possible. ;) --RalfLehmann
Additions:
.
> ''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 ;)
> ''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 ;)
Revision [1025]
Edited on 2004-08-18 21:49:37 by RalfLehmann [an easy solution for a problem (login/password/md5/javascript)]Additions:
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
Revision [1023]
Edited on 2004-08-18 20:29:25 by RalfLehmann [let's discuss some more (passwords/md5/javascript) :)]Additions:
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
Revision [1021]
Edited on 2004-08-18 16:43:39 by DreckFehler [clientside password encryption doesn't really help]Additions:
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
Revision [1018]
Edited on 2004-08-17 19:20:31 by RalfLehmann [login; MD5 password encrytion (client-sided)]Additions:
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...
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)
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...
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)
Deletions:
Revision [1017]
Edited on 2004-08-17 18:44:44 by RalfLehmann [login; MD5 password encrytion (client-sided)]Additions:
I have nothing special to say right now (except thank you for HideReferrers).
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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 login data) 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 solution that works for both javascript-enabled and javascript-disabled web clients... I haven't checked out each and every Wiki or CMS software yet to see how others handle it, though... ;)
--RalfLehmann, 2004-08-17
--[[http://www.worldwidewiki.net/wiki/RalfLehmann 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 login data) 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 solution that works for both javascript-enabled and javascript-disabled web clients... I haven't checked out each and every Wiki or CMS software yet to see how others handle it, though... ;)
--RalfLehmann, 2004-08-17
Deletions:
--[[http://www.worldwidewiki.net/wiki/RalfLehmann Ralf Lehmann]]
