www.webdeveloper.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 26

Thread: JS Password Protection

Hybrid View

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

    JS Password Protection

    This is a secure solution for password protection with JavaScript. It works by encrypting the password and the content. Nothing is revealed in the source code, and it cannot be beaten by disabling JavaScript.

    The download contains three files:
    Protect Content.html lets you generate your own protected content.
    Demo.html is a protected document, and as long as it remains unbroken, it's your proof that this software works. You can also use it as a template for your own protected pages.
    Demo, with hint.html is another protected document that tells you the password. This is meant to show that the first demo is not a trick or a fake.

    Enjoy! Feel free to reply with questions or comments.

    Download
    Last edited by Jeff Mott; 12-05-2009 at 09:25 PM.

  2. #2
    Join Date
    Sep 2006
    Location
    Copenhagen, Denmark
    Posts
    1,253
    But you still need the server to encrypt the data.
    #define question (2B || !2B)
    HTMLElement and W3C Event Handling in IE
    My JavaScript Library

    Don't PM me about answers to questions. If I don't reply in a thread it's because:
    • You didn't read the message posting guidelines
    • Your code is too unstructured and/or formatted poorly - correcting it is too time consuming
    • I simply don't know the answer

  3. #3
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    Only if you're delivering database-driven content, and the people who come asking for JS password protection usually aren't. So we're only dealing with static pages, which are prepared by the developer in advance.
    Last edited by Jeff Mott; 09-02-2008 at 10:33 PM.
    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. #4
    Join Date
    Jan 2005
    Posts
    3,067
    Using JS for password protection is pointless. It is true that the JS ecnryption you are using is better than most, but having the encryption method embedded in the page is still inpractical and causes a major security problem.

  5. #5
    Join Date
    Sep 2006
    Location
    Copenhagen, Denmark
    Posts
    1,253
    Only if you're delivering database-driven content.
    True
    And the people who come asking for JS password protection usually aren't.
    Not sure about that. If they are not then they get a false sense of security.
    but having the encryption method embedded in the page is still inpractical and causes a major security problem.
    Yes a little inpractical, but using a known algorithm is no security threat. Many widely used algorithms for cryptography is publicly available - and should be.
    Last edited by Dok; 08-28-2008 at 07:08 AM.
    #define question (2B || !2B)
    HTMLElement and W3C Event Handling in IE
    My JavaScript Library

    Don't PM me about answers to questions. If I don't reply in a thread it's because:
    • You didn't read the message posting guidelines
    • Your code is too unstructured and/or formatted poorly - correcting it is too time consuming
    • I simply don't know the answer

  6. #6
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    ...but having the encryption method embedded in the page is still inpractical and causes a major security problem.
    Honestly, it isn't a security problem at all. In fact, the best algorithms are not kept secret. They're open standards.

    Anytime you submit a credit card # or SSN over an HTTPS connection, you're relying on open and publicly available encryption algorithms. That they have been under public scrutiny for years and are still unbroken is a testament to their strength.

    The Rabbit cipher I used has been publicly available since 2003 and is still unbroken.
    Last edited by Jeff Mott; 08-29-2008 at 07:17 PM.
    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";

  7. #7
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    ...they get a false sense of security
    How so? The solution I posted offers true security.

    ...Yes a little inpractical...
    Again may I ask how? The only complaint you might have is needing to download the JS file. But it's only 4.41KB. That's not at all unreasonable.
    Last edited by Jeff Mott; 01-22-2009 at 04:02 PM.
    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";

  8. #8
    Join Date
    Sep 2006
    Location
    Copenhagen, Denmark
    Posts
    1,253
    How so? The solution I posted offers true security.
    If they are using a server-side language to generate code and sending it in plain text to the client. Newcommers to JavaScript might not have a thorough understanding of how things work and may so misunderstand how your script works.
    Again may I ask how so? The only complaint you might have is needing to download the JS file. But it's only 6.6KB. That's not at all unreasonable.
    My subjective meaning. Others might not find it inpractical.
    #define question (2B || !2B)
    HTMLElement and W3C Event Handling in IE
    My JavaScript Library

    Don't PM me about answers to questions. If I don't reply in a thread it's because:
    • You didn't read the message posting guidelines
    • Your code is too unstructured and/or formatted poorly - correcting it is too time consuming
    • I simply don't know the answer

  9. #9
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    If they are using a server-side language to...
    If they're using a server-side language, then they should rightly be told to use that to implement password protection. This JS protection merely satisfies the small niche of users who don't have, or haven't learned, a server-side language.
    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";

  10. #10
    Join Date
    Dec 2003
    Location
    Bucharest, ROMANIA
    Posts
    15,428
    Quote Originally Posted by Jeff Mott
    If they're using a server-side language, then they should rightly be told to use that to implement password protection. This JS protection merely satisfies the small niche of users who don't have, or haven't learned, a server-side language.
    It's only a cypher-decypher matter, not a real server-level secure method. As long as the algorithm is to be seen, a javascript cypher can be decrypted, sooner or latter, by any good math teacher.

    A good comparison is:
    http://homepages.tesco.net/~andycarl...ut_enigma.html

  11. #11
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    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.
    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";

  12. #12
    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 09:53 PM.

  13. #13
    Join Date
    Mar 2005
    Posts
    767
    Well done, but you should put a crystal-clear warning on the encryption page that the strength of the password is magnitudes more important than it would be for a server-side solution. Having both the salt and the target SHA1 hash readily available leaves the door wide open for a dictionary attack, so a decently sized passphrase or an auto-generated password like NL5^8]7(t-B[t+g is an absolute must.
    Stop thinking, start drinking.

  14. #14
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    Choosing a good password is always important. But you're right that it's more so with this setup. I'll add a note to the "generate" page.
    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";

  15. #15
    Join Date
    Jul 2003
    Location
    The City of Roses
    Posts
    2,503
    New version 2.0.
    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";

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