PassWord.txt Date: Fri, 13 Jun 2003 17:39:44 +0100 To: ke3fl@yahoo.com From: "Chris Wright" | This is spam | Add to Address Book Subject: Password Bah humbug!!!! :( As I filled in your web form e-mailer, I didn't keep a copy. AFAIR.. Password=ANewOneForYou I am new to JS and have just started dabbling as you know from my BB postings, so excuse me if I go off at a tangent.... ;o) The devices you use are interesting and I learned a lot poring over, trying to work out how this stuff hangs together. 1. If the password resides on the server in a text document, why not put it into an htm file that can auto re-direct maybe to a similar named file with html/htm variation after a string of %%%%%%%%%%%. Such an html file could then also have dummy document.write(red_herring) stuff to elude etc. etc. and otherwise mess up, a frame document could use document write to make a "view source" approach get a very wrong steer. 2. I suggest the password is stored in an encoded form. A mild dose of public key encoding (I hesitate to use encryption as a description) say the password= "ABC" the ASCII codes would be 65, 66, 67. Lets take 50 off each and then multiply them 15*16*17= 4080. Now fuzzy the water with a non-linear function say the character index ^2 subtracted from the code, so now we have (15-1) *(16-4)*(17-9)=1344 now that's probably simple to reverse engineer, but it describes the idea. Now use more sophisticated algorithms and more non-linearity and even with the coding formula, it gets harder to find a matching input, especially as the password gets longer. 3. Q: Is it possible to address/store the .js file or the password/checksum data file in another protected directory that is not viewable (or ftp-able) by the user ? I don't know, but it would be a whole lot easier to hide stuff :o)) 4. The target page URL needs to be encoded too (or prying eyes can just work out where to point the browser next. That could be the next challenge, but maybe the successful password can be subjected to another form of manipulation to generate the URL, so one couldn't cheat - even if there were a multiple solutions to the password, it wouldn't route correctly. Hope that helps. Let me know Chris Wright - same year?? 1950 was a good one :o) G3YFL..... ----- Chris, Very good! Did you use Netscape to view the txt file? You didn't say. My IE does not show anything when I try. Yes the idea of using a redirecting HTM file is good, unless someone turns off JavaScript to get the file. Also, encoded is good but not for this test. This is NOT really a way to make JS have secure passwords, it's an exercise to show the problems with JS. I've tried to keep it as simple as I can with some misdirection to see what would happen. The problem with a protected directory might be that even I could not get the data from it unless I did something and then all the client would have to do is run the program from their machine & keep at it until they got the file. Perhaps piece by piece. Good ideas, keep trying! I'll see what I can do to hide the txt file as well.