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: Ry Nohryb on 11 May 2010 13:16 On May 11, 6:28 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > Ry Nohryb : > > Johannes Baagoe : > >> Ry Nohryb : > >>> The problem is that the decryption logic is exposed as source code > >>> in a JS function, and giving that plus the encrypted payload is > >>> giving too much to a decided cracker. > >> Not if the encryption used is any good. Security through obscurity > >> has long fallen out of fashion, all serious encryption schemes > >> assume that the enemy knows every detail of the algorithm. The > >> secret is in the key, and only in the key. > > Good point. So it would be just as secure as the pwd, right ? > > Save a most improbable weakness in AES, yes. > > > crack would that be, in your opinion ? > > Assuming the password has been chosen in a suitably random manner, > say, by random choice of the 62 English alphanumeric characters, with > a length of 13... safe enough for any reasonable purpose :) Overkill, > actually. Unless your secret is worth millions of dollars to state > or corporate security services, 10 characters should be enough. Great. That's awesome. Let's see if I got it right: if I use the chars a..z, A..Z, 0..9 in the password, with 10 chars I get like (31+31+10)^10 combinations (3.7e18), If I could test by the brute force 1e6 keys per second, I would need 3743906242624s === 62398437377m === 1039973956h= 43332248 days === 118718 years. Is that correct ? Is this why you say that 10 chars is safe enough ? > (Incidentally, if it *is* worth millions of dollars, the "million > dollar attack" is likely to be more efficient than any attempt of > cracking : "One million dollars on your account in the Cayman Islands > if you give us the secret".) LOL. Thanks, -- Jorge.
From: Dr J R Stockton on 12 May 2010 12:41 In comp.lang.javascript message <aOmdnWj-Up_v_nTWnZ2dnUVZ8r1i4p2d(a)gigane ws.com>, Tue, 11 May 2010 09:02:26, Johannes Baagoe <baagoe(a)baagoe.com> posted: >Dr J R Stockton : > >> Now consider a page consisting of two frames. One contains an >> ordinary "enter password" box, ten characters wide but accepting >> many more. The other frame contains the "meat" of the page, but in >> a hidden DIV encoded to the author's private key. > >Assuming the standard vocabulary of public-key cryptology, if anything >is *encrypted* with the author's *private* key, it may be *decrypted* >with his *public* key. Which, as its name implies, is publicly >available to anyone. > >In other words, that encryption is worthless from the point of view >of secrecy, but it provides a strong evidence of authenticity, which >is why one does that sort of things. In order to ensure secrecy, what >one does is to *encrypt* according to the *recipient's* *public* key. > >> To reveal the "meat", one needs the corresponding public key, > >If that key is indeed public, the assumption is that one has it. > >On the other hand, your scheme seems to be quite workable using >symmetric encryption and relying on other, secure means to transmit >shared secret keys. E.g., the "meat" is encoded in AES and base64-ed. >There are reasonable implementations of AES in javascript, fast enough >for a few kilobytes of web page content. For example, here : >http://www.movable-type.co.uk/scripts/aes.html Being able to remember the terminology correctly gives you a considerable advantage. This entry exemplifies a running problem with the FAQ; it grew in the past by adding (to a first approximation) the actual answers to actual questions, with the actual Subject lines. The original questions would have included more text, often clarifying the OP's need; and the selected answer probably fulfilled that need. To be generally useful and reliable, however, a FAQ answer must be adjusted to accommodate all reasonable interpretations of the Subject, the Subject having first been adjusted to be clear and worth answering. -- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. The page is rearranged, and the three tests now apply more widely.
From: Ry Nohryb on 13 May 2010 05:33 On May 13, 9:22 am, Johannes Baagoe <baa...(a)baagoe.com> wrote: > Garrett Smith : > > > I am wide open for suggestions on this entry. Neither the question > > nor the answer are clear. Perhaps: > > | FAQ Topic - How can I prevent access to resources in the browser? > > | > > | You can't. Scripts that attempt to password protect resources do not > > | provide any real security. > > | > > | Access to resources can be restricted by requiring authentication on > > | the server. > > I have to disagree. It is quite possible to encrypt the body element > of a web page using, e.g., AES, (...) For Smith the FAQ guardian the probability of (to read && !to comprehend) is almost 1. Maybe next year. -- Jorge.
From: Johannes Baagoe on 13 May 2010 06:03 Ry Nohryb : > Johannes Baagoe : >> Garrett Smith : >>> I am wide open for suggestions on this entry. Neither the question >>> nor the answer are clear. Perhaps: >>> | FAQ Topic - How can I prevent access to resources in the browser? | >>> | You can't. Scripts that attempt to password protect resources do >>> not | provide any real security. >>> | >>> | Access to resources can be restricted by requiring authentication >>> on | the server. >> I have to disagree. It is quite possible to encrypt the body element of >> a web page using, e.g., AES, (...) > For Smith the FAQ guardian the probability of (to read && !to > comprehend) is almost 1. I have to disagree with that too. Anyway, here is a quick and dirty proof of concept : http://baagoe.com/en/ES/encrypted.html I shall leave the group enough time to attempt to prove that it does not "provide any real security", and then publish the password. > Maybe next year. Maybe an hour or two will be enough, if it is acknowledged that the security seems to be adequate after all :) -- Johannes
From: Ry Nohryb on 13 May 2010 06:13
On May 13, 12:00 pm, Bwig Zomberi <zomberiMAPSONNOS...(a)gmail.com> wrote: > > Sending the password (encrypted or otherwise) to the client is simply a > wrong approach to security. The pwd never ever travels through the net, it's entered by the user of the page, and never ever leaves the client, it's just used to decrypt the payload and then can be destroyed. -- Jorge. |