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: Thomas 'PointedEars' Lahn on 11 May 2010 08:11 Garrett Smith wrote: > FAQ server wrote: >> ----------------------------------------------------------------------- >> FAQ Topic - How can I prevent access to a web page by >> using javascript? >> ----------------------------------------------------------------------- >> >> In practice you can't. While you could create a suitable >> encryption system with a password in the page, the level of >> support you need to do this means it's always simpler to do it >> server-side. Anything that "protects" a page >> other than the current one is definitely flawed. > > I actually don't know what "level of support" means here. > > Can the answer be shortened to: > > | You can't. Access to a page can be restricted by requiring user > | authentication on the server. > > ? No. That would imply "javascript" would be client-side only, especially that it could not be used server-side for user authentication. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Ry Nohryb on 11 May 2010 09:30 On May 10, 7:09 pm, Dr J R Stockton <reply1...(a)merlyn.demon.co.uk> wrote: > In comp.lang.javascript message <hs5grk$50...(a)news.eternal- > september.org>, Sat, 8 May 2010 22:22:54, Garrett Smith > <dhtmlkitc...(a)gmail.com> posted: > > > > > > >FAQ server wrote: > >> ----------------------------------------------------------------------- > >> FAQ Topic - How can I prevent access to a web page by > >> using javascript? > >> ----------------------------------------------------------------------- > >> In practice you can't. While you could create a suitable > >> encryption system with a password in the page, the level of > >> support you need to do this means it's always simpler to do it > >> server-side. Anything that "protects" a page > >> other than the current one is definitely flawed. > > >I actually don't know what "level of support" means here. > > >Can the answer be shortened to: > > >| You can't. Access to a page can be restricted by requiring user > >| authentication on the server. > > No. > > Firstly, the meaning of "access" must be clarified. > > If the page is accessible at all, nothing purely client-side can prevent > someone who wants to see the content from reading it, as served. > > At the other extreme, there's a significant proportion of authors who > firmly believe that the code of a page can ONLY be revealed using the > right-click menu. They are wrong; but disabling that menu will prevent > any of them seeing the code of a page. > > 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. To reveal the "meat", one needs the > corresponding public key, which goes (in Hex, reversed) into the > password box. Entering the "password" causes the encoded material be > decoded by said public key and revealed on another DIV. And add a bit > of distracting material in each page. That's very interesting for the user's password doesn't travel through the net. 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. -- Jorge.
From: Johannes Baagoe on 11 May 2010 10:09 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. -- Johannes
From: Ry Nohryb on 11 May 2010 11:59 On May 11, 4:09 pm, Johannes Baagoe <baa...(a)baagoe.com> wrote: > 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 ? Say I use AES and the pwd is 98Gh654f6z3sd, how safe/difficult to crack would that be, in your opinion ? -- Jorge.
From: Johannes Baagoe on 11 May 2010 12:28
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. (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".) -- Johannes |