The "security blanket" factor
by
__aavhli5779
·
· Score: 5, Insightful
I had this idea myself, and abandoned it because I realized just how much of a sense of security people get from having that little "lock" in the corner*. Though there are plenty of advantages to a strictly client-side security model, I still wonder how the unwashed ignorati surfing ecommerce sites who have had "MAKE SURE YOU HAVE ENTERED AN ENCRYPTED PAGE" drilled into them will take to this sort of idea.
Then again, if some sort of certification authority could be set up for Javascrypt-ed pages where the user was somehow assured that their data was equally protected as would be over https, then things would be more preferable. However, the byzantine red-tape behind getting a cert is possibly one of the things this technology would do away with best, and it would be a pity to remove such an obvious advantage.
In any case, it's promising, and I hope it is successful.
It's all good in theory, but when people happily send their credit card number to any random website claiming to seel stuff that does an SSL connection, just what is the point?
The point is that if you connect with SSL - then the website is not "random". I.e. you can verify that whoever pretends to be amazon.com - is really amazon.com. So you know who you are dealing with - you are not giving your credit card to somebody just pretending to be amazon.com.
Also you made sure that nobody could sniff the credit card number while it was traveling from you to amazon.com.
Or you could tell your poker buddies the key in person and then send the stuff to them once you get home and have complete security with your friends, even if you know that they would never understand "real" encryption.
That gives you security real cheap. I know something like GPG is free and assymetrical and all that, but it's not necessarily cheap in that you have to set it up at every point and educate all the users. This scheme doesn't even make you send an encrypted key to the person beforehand, which eliminates an extra step that Joe and Bob might not care about while they swap stories about cheating on their wives.
No highly secretive government assassin and spy program (or the equivalent) would use something like this for sure, but they're not the audience. This is more of a toy than anything, useful for personal stuff instead of sensitive stuff.
--
I design user interfaces for a free network management application,
Re:Nice, but dangerous.
by
tomstdenis
·
· Score: 5, Insightful
This is totally stupid. First off the js runs *locally*. The real risk is making sure the js you download is legit.
There is no risk of data going outwards though unless the js has been modified.
-- Someday, I'll have a real sig.
Re:Nice, but dangerous.
by
TheSpoom
·
· Score: 2, Insightful
Uh, it's Javascript. The entire point is that processing is done client-side. No information is submitted to the site. There's no HTTPS or SSL because nothing is transmitted.
-- It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
The problem is knowing when you're dealing with legitimate Javascrypt encryption, and when it may be some malicious code instead (see my post above regarding certification).
Also there's still no way of ensuring that your data, once received on the server-side, will be used properly. That will, as always, come down to an issue of trust between you and the vendor.
Re:Nice, but dangerous.
by
evilviper
·
· Score: 4, Insightful
in this guy's site, because he can read it, and because it's not over a HTTPS or SSL connection, so can anyone else.
NO! The data never leaves your browser. Therefore, nobody on the net can see it under any circumstances. Also, unless there is a trojan piece of javascript code that submits it to his site (a potential problem with a program in any languge) he can't possibly see it either.
Re:useful
by
Anonymous Coward
·
· Score: 1, Insightful
It's worse than a hack. It accomplishes nothing.
People use encryption when sending passwords, so others can't intercept the passwords and use them. Now you're sending hashes over the network. Others can just intercept the hashes and use them. The attackers won't know what the original passwords were, but what do they care? They can still log in to those accounts.
This isn't secure
by
ArkanWindsong
·
· Score: 3, Insightful
The problem with hashing a password with js and then just sending the hash is that the hash effectively becomes the password. i.e. all someone needs to do is eavesdrop your http session and record the hash value. The attacker can then send that same hashed value to the server and login as you.
The server must hash the password itself or it isn't secure. Or the hash value must be protected as much as the password.
JavaScript RULEZ!!1!
by
Vagary
·
· Score: 2, Insightful
It's not yucky! JavaScript is one of the most elegant of scripting languages.
You have features like higher-order functions (well kinda), basic OO, and built-in regular expressions. C-like syntax with simplicitly totally unlike Python and Perl. And talk about platform independence! If JavaScript had just a few more libraries I think I'd advocate it as a great beginner language...
ECMAScript runs on the localhost
by
autopr0n
·
· Score: 3, Insightful
If you want to, you should be able to download the page, disconnect from the internet, and still encrypt/decrypt data.
In other words, you don't really understand what's going on. Although it would be a good idea to to check the page source to make sure that it dosn't upload your data...
-- autopr0n is like, down and stuff.
shouldn't this be called ECMASCrypt?
by
autopr0n
·
· Score: 4, Insightful
I mean really, people are confused enough about the difference between Java and Javascript (which basically have nothing to do with each other other then some brain-dead attempt at synergistic marketing. JS was originally going to be called Livescript)
-- autopr0n is like, down and stuff.
Re:Javascript insecurity
by
Phroggy
·
· Score: 2, Insightful
Are you talking about JavaScript itself, or a particular implementation of it?
-- $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$]; $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Encryption, only for protecting privacy?
by
imaginaryNumber
·
· Score: 2, Insightful
'The sole reason for encryption is to protect privacy.'
Statements like this from developers of a 'high-security data encryption solution' make me worried.
And assertions that transparency will make software secure always presume that someone with the 'required expertise to pass judgment' will actually do so.
Diffie-Hellman is indeed an algorithm for producing a shared secret without authentication. And indeed, anything without authentication is exposed to a man-in-the-middle attack. That's why SSL doesn't use Diffie-Hellman for authentication, only for (help with) producing a shared secret key.
In SSL, the client verifies the site by means of a certificate that the site provides; this cert has nothing to do with Diffie-Hellman. The site could use SSL to verify the client identity, but this option isn't used when selling stuff to the general public, as the site has no identity it would wish to bind to the client. (Well, a client cert binding the client to a credit card might be considered useful, but until the CC companies mandate it -- and they won't -- the shopping site has no need to check it.)
Having a cert protects you from man-in-the-middle.
The problems with authentication are due to problems on the client side with binding the site's cert to the site's identity. The typical client (a web browser) does the only things it can: It verifies that it trusts the signatory on the cert (so it trusts that the information about the site's identity, as presented on the cert, is correct), and that the cert belongs to the URL displaying the page. Then it leaves it to the user to decide whether to trust the site. Of course, many sites use some third party to handle payments, leaving the poor user the question of whether to trust buystuff.com when buying from ariels.com. And some sites manage to use a cert from the wrong domain, so the browser pops up a warning. And, of course, it's not at all clear to the user how to validate the identity from a cert.
But SSL, as used on shopping sites, does give protection from a man-in-the-middle.
Slashdot Mirror
I had this idea myself, and abandoned it because I realized just how much of a sense of security people get from having that little "lock" in the corner*. Though there are plenty of advantages to a strictly client-side security model, I still wonder how the unwashed ignorati surfing ecommerce sites who have had "MAKE SURE YOU HAVE ENTERED AN ENCRYPTED PAGE" drilled into them will take to this sort of idea.
Then again, if some sort of certification authority could be set up for Javascrypt-ed pages where the user was somehow assured that their data was equally protected as would be over https, then things would be more preferable. However, the byzantine red-tape behind getting a cert is possibly one of the things this technology would do away with best, and it would be a pity to remove such an obvious advantage.
In any case, it's promising, and I hope it is successful.
___________________
*also I am a poor coder
This is totally stupid. First off the js runs *locally*. The real risk is making sure the js you download is legit.
There is no risk of data going outwards though unless the js has been modified.
Someday, I'll have a real sig.
Uh, it's Javascript. The entire point is that processing is done client-side. No information is submitted to the site. There's no HTTPS or SSL because nothing is transmitted.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
For some reason I thought that if you had a good reason to encrypt your content, you'd be using a secure medium in the first place. :)
I don't call a website with no security measures with a neat JavaScript thang "security".
Have a good day,
Clif
clifgriffin > blog
NO! The data never leaves your browser. Therefore, nobody on the net can see it under any circumstances. Also, unless there is a trojan piece of javascript code that submits it to his site (a potential problem with a program in any languge) he can't possibly see it either.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
It's worse than a hack. It accomplishes nothing.
People use encryption when sending passwords, so others can't intercept the passwords and use them. Now you're sending hashes over the network. Others can just intercept the hashes and use them. The attackers won't know what the original passwords were, but what do they care? They can still log in to those accounts.
The problem with hashing a password with js and then just sending the hash is that the hash effectively becomes the password. i.e. all someone needs to do is eavesdrop your http session and record the hash value. The attacker can then send that same hashed value to the server and login as you.
The server must hash the password itself or it isn't secure. Or the hash value must be protected as much as the password.
It's not yucky! JavaScript is one of the most elegant of scripting languages. You have features like higher-order functions (well kinda), basic OO, and built-in regular expressions. C-like syntax with simplicitly totally unlike Python and Perl. And talk about platform independence! If JavaScript had just a few more libraries I think I'd advocate it as a great beginner language...
If you want to, you should be able to download the page, disconnect from the internet, and still encrypt/decrypt data.
In other words, you don't really understand what's going on. Although it would be a good idea to to check the page source to make sure that it dosn't upload your data...
autopr0n is like, down and stuff.
I mean really, people are confused enough about the difference between Java and Javascript (which basically have nothing to do with each other other then some brain-dead attempt at synergistic marketing. JS was originally going to be called Livescript)
autopr0n is like, down and stuff.
Are you talking about JavaScript itself, or a particular implementation of it?
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Statements like this from developers of a 'high-security data encryption solution' make me worried.
And assertions that transparency will make software secure always presume that someone with the 'required expertise to pass judgment' will actually do so.
I thought MD5 was cracked?
Diffie-Hellman is indeed an algorithm for producing a shared secret without authentication. And indeed, anything without authentication is exposed to a man-in-the-middle attack. That's why SSL doesn't use Diffie-Hellman for authentication, only for (help with) producing a shared secret key.
In SSL, the client verifies the site by means of a certificate that the site provides; this cert has nothing to do with Diffie-Hellman. The site could use SSL to verify the client identity, but this option isn't used when selling stuff to the general public, as the site has no identity it would wish to bind to the client. (Well, a client cert binding the client to a credit card might be considered useful, but until the CC companies mandate it -- and they won't -- the shopping site has no need to check it.)
Having a cert protects you from man-in-the-middle.
The problems with authentication are due to problems on the client side with binding the site's cert to the site's identity. The typical client (a web browser) does the only things it can: It verifies that it trusts the signatory on the cert (so it trusts that the information about the site's identity, as presented on the cert, is correct), and that the cert belongs to the URL displaying the page. Then it leaves it to the user to decide whether to trust the site. Of course, many sites use some third party to handle payments, leaving the poor user the question of whether to trust buystuff.com when buying from ariels.com. And some sites manage to use a cert from the wrong domain, so the browser pops up a warning. And, of course, it's not at all clear to the user how to validate the identity from a cert.
But SSL, as used on shopping sites, does give protection from a man-in-the-middle.
2 dashes and a space, or just 2 dashes?