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.
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.
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.
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.
...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.
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.
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.
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.
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.
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.
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.
Reply With Quote
Originally Posted by Jeff Mott
Bookmarks