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.
___________________ *also I am a poor coder
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.
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.
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.
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)
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.
The encryption is suitably strong.
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.
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
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.
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.