FAQ Topic - How can I prevent access to a web page by using javascript? (2010-05-09)
in [JavaScript]
|
Prev: THE LAST ONLINE CASINO SECURITY LINE
Next: FAQ Topic - How can I prevent access to a web page by using javascript?(2010-05-09)
From: VK on 16 May 2010 06:38 On May 16, 7:00 am, Johannes Baagoe <baa...(a)baagoe.com> wrote: > > The page URL to navigate has to be in the regular format, so easy > > to copy-paste from the address bar or from right-click => properties. > > And so what ? So the end of it. > > Same for XHR call => document HTML replacement, just will take an extra > > minute to see the algorithm. > > In case you missed the discussion, the page is here :http://baagoe.com/en/ES/encrypted.html > > Inspect the code to your heart's content, and see if you can get in. > (That is, without looking up the password I published later.) Oh, com'on, please... I am not going to the "chicken sh**" calls for a longest time. If you really want to know where is the failure of your approach, try comp.lang.java.security (having the algorithm ported to Java of course). In the last century comp.lang.java.security was what sci.lang was for the Fermat's Last Theorem. Just like anyone comes to sci.lang for yet another "FLT simple proof", any new "encryption genious" used to come to comp.lang.java.security with yet another "bulletproof" encryption with both key and decoding in one block of code. Some regulars used to have fun by posting the key, amount of milliseconds spent and a short note where the poster went wrong. If they are still there and not tired of that, you'll get an answer. > > I don't think that a "history of perpetuum mobile development attempts" > > would be suitable for FAQ. > > Quite, but sometimes, something that was dismissed as a perpetuum > mobile turns out to be more like Columbus's egg. Sure. To not make myself looking as a retrograde person: I never claiming on something "it is not possible because it is not possible". Yet if someone comes with a perpetuum mobile schema of wheel A turning wheel B which turning wheel A, I can state immediately that it doesn't work - without studying all details of how "two wheels turning each other" was obfuscated in this time. Same for secure solutions of key and description algorithm being in the same execution block. I don't know exactly where it is wrong, I just know that it is wrong.
From: Johannes Baagoe on 16 May 2010 06:47 VK : > yet another "bulletproof" encryption with both key and decoding in > one block of code. [...] > Same for secure solutions of key and description algorithm being in > the same execution block. I don't know exactly where it is wrong, > I just know that it is wrong. What makes you assume that the key is anywhere in the code ? -- Johannes
From: VK on 16 May 2010 07:06 On May 16, 2:47 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > VK : > > > yet another "bulletproof" encryption with both key and decoding in > > one block of code. > > [...] > > > Same for secure solutions of key and description algorithm being in > > the same execution block. I don't know exactly where it is wrong, > > I just know that it is wrong. > > What makes you assume that the key is anywhere in the code ? I trust you that you play fairly and that it's a purely client-side Javascript solution, so using only static Javascript code and (possibly) any amount of static client-side data files. If it's so, then the rest is easy. Again: ask comp.lang.java.security, they had zillions of key+decoder-noKeyExchange solutions, yours is not the most obfuscated one from what I saw.
From: Ry Nohryb on 16 May 2010 07:10 On May 16, 12:07 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > Ry Nohryb : > > > If I understand it correctly, you look for an irregular, non-flat > > distribution of frequencies. Well, it's ok, but as you know beforehand > > which elements should exhibit a higher than average frequency, > > you could as well, ISTM, look directly for that, as I did in my > > isHumanTxt() code snippet, don't you think so ? > > Quite, the method I posted is for the general case where we don't know > what to look for, except that it is not random. Very often, one knows > a lot more than that, and a simpler test like yours may be sufficient. > > You, on the other hand, go to the other extreme and assume it is > ASCII. Lots of human texts are not. Your test would fail on Russian > or Greek, mine would recognize Chinese and even cuneiform. (Not to > mention that some people who use non-English alphabets might object > to not being considered human.) And rightly so! For unknown payload types, the unix file command might be of help. -- Jorge.
From: Ry Nohryb on 16 May 2010 07:20
On May 16, 1:06 pm, VK <schools_r...(a)yahoo.com> wrote: > > I trust you that you play fairly and that it's a purely client-side > Javascript solution, so using only static Javascript code and > (possibly) any amount of static client-side data files. > If it's so, then the rest is easy. Again: ask comp.lang.java.security, > they had zillions of key+decoder-noKeyExchange solutions, yours is not > the most obfuscated one from what I saw. VK, have you read this thread before posting ? All of it ? In any case I think you should. (read or re-read it, whatever). -- Jorge. |