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: Garrett Smith on 13 May 2010 13:26 Bwig Zomberi wrote: > Johannes Baagoe wrote: >> Bwig Zomberi : >> >> [...] > So, the FAQ should say that while it is possible to do it on the > client-side (browser), it is not the recommended way. The web > application should be in control. Server-side code should authenticate > access. Sending encrypted content to unauthorised users would make the > content susceptible to brute-force and weakness attacks. > Encrypted strings is a different matter. It is not possible to prevent access to publicly accessible resources, such as attempted by scripts that do things like: var pwd = prompt("enter password"); location.href= pwd + ".html"; -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Johannes Baagoe on 13 May 2010 13:50 Garrett Smith : > Encrypted strings is a different matter. > It is not possible to prevent access to publicly accessible resources, > such as attempted by scripts that do things like: > var pwd = prompt("enter password"); > location.href= pwd + ".html"; Quite. And of course, if *that* is what the author of the question had in mind, a firm advice against it is appropriate. But the question just might be a little less naive, say by someone who has picked up a few genuine notions of cryptology, but no real expertise, or at least none in cryptology implemented in javascript. -- Johannes
From: Ry Nohryb on 13 May 2010 14:19 On May 13, 7:17 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > Ry Nohryb : > > > there's still the question of how to know when to stop, if you hadn't > > given me the .substring(0,5) ==== "*****" hint ? > > Suppose the very worst case : you know absolutely nothing about the > plaintext, except that it is supposed to be read and understood by humans.. > > What simple property would still quite decisively set it apart from the > decryption with a wrong key ? No idea. > How could you test that property by program ? No idea. I'd need to know a way to validate decrypt(crypt, key). Unless encrypt(decrypt(crypt, wrongKey), wrongkey) !== crypt, and, encrypt(decrypt(crypt, theRightKey), theRightKey) === crypt. BTW, the rate I told you (180KHz) was per 30 seconds, not per second. -- Jorge.
From: Johannes Baagoe on 13 May 2010 15:49 Mike Duffy : > Johannes Baagoe : >> Garrett Smith : >>> It is not possible to prevent access to publicly accessible >>> resources, such as attempted by scripts that do things like: >>> var pwd = prompt("enter password"); location.href= pwd + ".html"; >> Quite. And of course, if *that* is what the author of the question >> had in mind, a firm advice against it is appropriate. > Why? As long as the server does not yield a list of available pages, > it should work to restrict access to people that know the password. Except that the "password" shows up in plain text in the URL that is fetched in. I wouldn't trust such a mechanism even to hide my early portraits in the bathtub from my mother-in-law. -- Johannes
From: Johannes Baagoe on 13 May 2010 16:41
Ry Nohryb : > I'd need to know a way to validate decrypt(crypt, key). Unless > encrypt(decrypt(crypt, wrongKey), wrongkey) !== crypt, and, > encrypt(decrypt(crypt, theRightKey), theRightKey) === crypt. There is an easier way: decryption with a wrong key will always return pseudo-random numbers, that is, with an approximately uniform distribution. Whereas humanly readable text will always have quite distinctive structure, often more or less according to Zipf's law, and always characteristic of the relevant encoding, be it ASCII, UTF-8, ISO 8859 or whatever. So even in the extraordinary case where we can't guess the encoding, it is simply a matter of using a goodness-of-fit test of the observed byte frequencies against the null hypothesis that the distribution is uniform, which will be the case unless we have found the key. Chi-square serves well and is quite fast. (Of course, that won't work if the plain text has been compressed, e.g., by LZW, *before* being encrypted - always a sensible thing to do. But inspection of the code shows that it is not the case.) > BTW, the rate I told you (180KHz) was per 30 seconds, not per second. OK, that means it would take more than thousand years to try all combinations - at present speed, which of course doesn't make sense. But anyway - brute force is out, at least with ordinary means. And if AES is seriously flawed, it would be a major sensation, all the very competent people who have given it their approval, both academics and in the NSA and other agencies, would look very foolish indeed - I don't think so. I am slightly less happy with the mode of operation. CTR would not be my choice, but I was too lazy to rewrite the function in CBC or OCB, and anyway, it is probably good enough. I should check the details, though, therein lies the devil. By and large, I believe I have proved my point. Here is the key: Riekei1e (the next to last character is a one, not an el) The question is now: is it sufficiently interesting to justify the rather boring task of turning into a proper application ? A very small one, admittedly, but it still requires work. -- Johannes |