www.webdeveloper.com
Page 2 of 2 FirstFirst 12
Results 16 to 26 of 26

Thread: JS Password Protection

  1. #16
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    New version 4.0.

    Felgall, this is mostly for you. You are nearly the only outspoken fan of this script, so I figured I ought to cater to you, and I know how you love small file sizes.

    I replaced the Rabbit cipher with a strengthened variant of RC4. RC4 is one of the simplest and smallest ciphers around, and with some enhancements, still secure.

    The new JS include size is 3.77KB.

    Enjoy.
    for(split(//,'))*))91:+9.*4:1A1+9,1))2*:..)))2*:31.-1)4131)1))2*:3)"'))
    {for(ord){$i+=$_&7;grep(vec($s,$i++,1)=1,1..($_>>3)-4);}}print"$s\n";

  2. #17
    Join Date
    Aug 2009
    Posts
    8
    After searching a lot.. I think this is the one I want to use.... But.. HOW. I downloaded the zip file.. opened the *html files but NADA on how to make it work for me..

    Bearing in mind that my web crafting abilities are "low" any one with a tutorial or advice on where to paste / place content to make this work..

    Do I use the "Generate Encrypted Content.html" page to encrypt my password? then where do I put it.. Or.. how do I pick my own password to use with this..?

    Thanks for any help advice

  3. #18
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    Hi Ralph,

    What you want to do first is to open "Generate Encrypted Content." In the box labeled "plaintext," type whatever content you want to protect. In the box below that, labeled "password," type the password you want to use. Then at the bottom of the page, press "Compute." Your encrypted password and content will appear in the "Result" box.

    For the next step, it will probably be easier to start working from one of the demo pages. Open "Demo Protected Page 2" in your text editor. Find the two lines where the variables "hpw" and "ct" are set, then replace those two lines with your result from step one.

    And that's it. Your content is now securely protected. You may of course customize the rest of the page however you wish.

    Enjoy!
    for(split(//,'))*))91:+9.*4:1A1+9,1))2*:..)))2*:31.-1)4131)1))2*:3)"'))
    {for(ord){$i+=$_&7;grep(vec($s,$i++,1)=1,1..($_>>3)-4);}}print"$s\n";

  4. #19
    Join Date
    Aug 2009
    Posts
    8
    Thanks Jeff, I will have a go at making it work tomorrow. It may make more sense when I actually get into it.

    But, you say in the "plain text" box to type in the content I want to protect... I want to protect all my site... Do you mean to type in the name of each page in the site?

    This site..(planned and in development) is one for family members only.. I envision a log in page.. for family members only.. good password...access to the rest of the site, bad password.. to a "we are sorry" page.

    Is your program the wrong one for this type of control?

  5. #20
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    Anything JavaScript is the wrong choice for this type of control.

    What I provided could be extended to protect an entire site rather than just a single page, but it would take an awful lot of time and effort to manage it.

    You should only use a JavaScript solution if you absolutely must, such as if you're distributing a Web site on CD with a protected section. Otherwise, you should use a server-side solution.
    for(split(//,'))*))91:+9.*4:1A1+9,1))2*:..)))2*:31.-1)4131)1))2*:3)"'))
    {for(ord){$i+=$_&7;grep(vec($s,$i++,1)=1,1..($_>>3)-4);}}print"$s\n";

  6. #21
    Join Date
    Aug 2009
    Posts
    8
    Thanks again Jeff
    My "prototype" site will be temporarily hosted in my personal web space provided by my ISP.. they do not allow server side scripting thus the quest for some sort of temporary control to my site. If approved by the bulk of the family then I will subscribe to a hosting site and implement a proper login process.

    I did play with your "program" and can see possible uses for it later... but for now, having it open page 1 if true and page 2 if false is sadly beyond my abilities

    So the quest goes on.. but, the process is in itself useful as there is so much to learn.. and so many different approaches to similar problem

  7. #22
    Join Date
    Mar 2010
    Posts
    672
    Quote Originally Posted by Jeff Mott View Post
    Cypher-decyphering, as you call it, is a secure method. For instance, when you submit a credit card number or a social security number over an SSL connection (https), encryption is what keeps that information safe. Or when you use SFTP (secure FTP), you're relying on encryption. Even when you password protect your browser-saved passwords, you're relying on encryption then too.

    These are all open algorithms. Anyone may examine them, even math teachers. But not even the world's best cryptographers can break them. That's why they're used to protect the most sensitive information sent through the Internet.

    You may distrust them if you wish, but it's wrong to say they aren't secure.
    Sorry but that is a horribly flawed view of encryption. SSL/TLS is based on public key encryption, where as you stated the beauty is that the the key for encrypting the data is publicly available. The difference between that and your javascript code (though quite useful for those who need it i'm sure) is that public key encryption keeps the so called "private key" unknown, which is for the decrypting. Once that private key is known (and has happened before via unintentional information leaks) the encryption is broken. Having both the encryption and decryption methods known publicly makes the algo used pointless. You're correct that rc4 is secure... but the failure in most crypto algos usually is the implementation, not the algo itself (aka WEP, which used rc4). I have yet to look at your code, but i can guarantee you that it is not as secure as you think it is. I'd highly discourage anyone from using this method for data that truly needs to be secure and only use it to protect from casual crackers.

    p.s. The algo's used by SSL are indeed crackable, it has nothing to do with analysis of them as their workings are quite well known. The issue is that, without the private key, they require a rather large amount of processing power to do factors for the decryption. This is one reason why some are worried about quantum computers as they make factoring large numbers a breeze. Thats one reason for the constant increasing of the number of bits (128, 256...etc) used for such encryption, as the average amount of processing power increases, the amount of bits used for encryption must also increase to avoid it being crackable without having a ton of resources at your disposal.
    Last edited by Jarrod1937; 01-15-2011 at 10:53 PM.

  8. #23
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    Quote Originally Posted by Jarrod1937 View Post
    ...where as you stated the beauty is that the the key for encrypting the data is publicly available...
    I said the algorithms were publicly available. I did not say the key was publicly available. That crucial difference could have saved you a lot of typing.

    Quote Originally Posted by Jarrod1937 View Post
    ...I have yet to look at your code, but i can guarantee...
    I realize that almost all JavaScript-based password protection schemes out there are insecure, so I don't blame you for jumping to conclusions, but in this case, you really should give it a try before you make any guarantees.

    Quote Originally Posted by Jarrod1937 View Post
    The algo's used by SSL are indeed crackable ... as the average amount of processing power increases, the amount of bits used for encryption must also increase to avoid it being crackable
    Yes. In fact, using computers to try random keys or passwords, one after another after another -- called a brute force search -- is always a possible attack against any encryption system (with one, impractical exception). But if guessing at the key until you find the right one is the most effective attack, then the encryption has done its job, and the algorithm is considered secure.
    for(split(//,'))*))91:+9.*4:1A1+9,1))2*:..)))2*:31.-1)4131)1))2*:3)"'))
    {for(ord){$i+=$_&7;grep(vec($s,$i++,1)=1,1..($_>>3)-4);}}print"$s\n";

  9. #24
    Join Date
    Mar 2010
    Posts
    672
    Quote Originally Posted by Jeff Mott View Post
    I said the algorithms were publicly available. I did not say the key was publicly available. That crucial difference could have saved you a lot of typing.
    True enough, it was more so the (perceived) conflation of general encryption with public key cryptography that elicited that response. The main security of your code relies on one way hashing algos (sha1), yet you were using ssl (public key) as an example for arguing its security. Until i looked at your code i wasn't sure if you were trying to do a sort of public key encryption but purely client side, which indeed would be pointless.

    I realize that almost all JavaScript-based password protection schemes out there are insecure, so I don't blame you for jumping to conclusions, but in this case, you really should give it a try before you make any guarantees.
    After looking at your code, it is indeed quite clever, while the salt is known it is long enough that the computed hash using sha1 is not vulnerable to rainbow tables (though i don't know what length they've been developed to these days), at least when paired up with a good password. However, there definitely is the vulnerability to a dictionary attack as previously mentioned, so hopefully a good password is chosen. But with that said it is indeed pretty secure, and is impressive especially since its done client side. However, for fear of an implementation vulnerabilities (even though i don't see any right off the bat), and dictionary attack if the user isn't careful enough, i'd still not recommend it for something super secure... but those who would use this i'd imagine wouldn't be storing anything that secure (i'd hope).
    But i do take back my original statement, you've put together an impressive piece of code that does do a pretty secure implementation of encryption using javascript (something i've yet to see before).


    Yes. In fact, using computers to try random keys or passwords, one after another after another -- called a brute force search -- is always a possible attack against any encryption system (with one, impractical exception). But if guessing at the key until you find the right one is the most effective attack, then the encryption has done its job, and the algorithm is considered secure.
    Well, that's not entirely what is meant by the factoring problem of public key cryptography, which is the attempt to factor/deconstruct the modulus into its original factors in order to find the private key, its not quite what i'd call brute force in the traditional sense as traditionally you'd be directly brute forcing the key needed for decryption (the private key itself), though thats just a difference of definition i suppose, but point taken.

  10. #25
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    Quote Originally Posted by Jarrod1937 View Post
    ...yet you were using ssl (public key) as an example for arguing its security.
    I suppose I'll recap the thread for you...

    konithomimo argued that if the algorithm is publicly known, then it's inherently insecure. I knew that wasn't true, and to make the case, I cited security systems that are widely regarded as secure and which are also publicly available.

    That's where the reference to SSL came from.

    Quote Originally Posted by Jarrod1937 View Post
    However, there definitely is the vulnerability to a dictionary attack as previously mentioned, so hopefully a good password is chosen.
    Yes, dictionary attacks are always possible in any system where a user picks their own password.

    Quote Originally Posted by Jarrod1937 View Post
    for fear of an implementation vulnerabilities (even though i don't see any right off the bat), and dictionary attack if the user isn't careful enough, i'd still not recommend it for something super secure.
    Un huh... for the vulnerabilities you can't find, and for the generic attacks that apply to every security system...

    You make a strong case.

    Sorry for the sarcasm, but... seriously?
    Last edited by Jeff Mott; 01-16-2011 at 01:30 AM.
    for(split(//,'))*))91:+9.*4:1A1+9,1))2*:..)))2*:31.-1)4131)1))2*:3)"'))
    {for(ord){$i+=$_&7;grep(vec($s,$i++,1)=1,1..($_>>3)-4);}}print"$s\n";

  11. #26
    Join Date
    Mar 2010
    Posts
    672
    To make my reply simple, i agree with you after looking over my responses a bit more (admittedly some were a bit nonsensical). I had initially misread the post that i initially replied to. And after thinking about it a dictionary attack is indeed possible on any system for which the user chooses their own password (serious brain fart there...). Well, i'm heading to bed to get some sleep (which apparently i need).

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center



Recent Articles