Some of these are free, some are Free and some are neither. Personally, I've written banking software using the RSA libs (I tried to get use BouncyCastle but management didn't like the name!).
--
----
Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
For quite a good long time now (in computer terms that is) Yahoo has been doing this same thing. If you log-in without entering SSL mode, you need to have javascript enabled in your browser so that the script can MD5-encrypt your password.
Despite the whole client-side-encryption advantage, I dislike how much easier it would be to perform a man-in-the-middle, or a number of other exploits. I will admit, however, that I am quite concerned with the prospect of honeypot SSL sites, designed to steal info, but I think the former is more likely. So, for now, I am sticking with SSL. Maybe in conjunction with SSL, this would make an ideal solution. Of course, SSH would be even better...
Re:No GPG?
by
Anonymous Coward
·
· Score: 1, Informative
Hushmail uses a Java applet to encrypt mail - maybe you could get your grandmother to use that. There are other Java crypto implementations, such as Cryptix. Packaging one as an applet shouldn't be too hard.
I'm already seeing people mix the two up in this thread, let's set this down straight:
JavaScript/ECMAScript: Untyped yucky scripting language developed by Netscape (IIRC) and built into browsers so you can have image rollovers.
-- has nothing whatsoever to do with --
Java: OO, multi-threaded, multi-platform language used occasionally on websites as applets, but much more frequently on the back end for app servers and the like.
This has been a public information posting.
--
----
Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
It's true that JavaScript and Java have little in common. The name was a marketing ploy. (It was originally called LiveScript.) But JavaScript does have types-- in fact, it's an oo language.
The algorithm Javascrypt implements is absolutely useless for what you're talking about. AES is a symmetric encryption algorithm, which means that if you're going to send the data to some server using Javascrypt, at some point you need to communicate the key. If you send the key with the data (not to mention the.js for decryption), you've just royally wasted your time. This could only be useful if you agree to a key in advance using some non-internet connection method, in which case you're not going to go with a "cheap ass" encyption technique like this.
(I do not mean to disparage the Javascrypt work, it's good stuff. But it's more useful to introduce people to encryption then for any practical use.)
The genius of asymmetric encryption is that you can negotiate a secure connection without compromising it; it is not immediately obvious this should be possible and I consider it one of the larger mathematical results of the previous century. Extensions of that work have resulted in the ability to "sign" the keys during exchange. None of this applies to symmetric encryption because you have to agree on a key directly with the sender. (You could in theory still provide a third-party affirmation of the validity of a given key with symmetric encryption but not without giving the third party the key, which is undesirable. With asymmetric encryption the third party can sign a public key without knowing the private key that generated it, so even though Verisign signs your key it does not mean that Verisign can read through the resulting encrypted connection.)
A lot of people seem to be laboring under this misconception. Javascrypt is a neat toy and a valuable educational tool. It is not and can not replace SSL or the SSL layer of the browser. If someone wants to implement a version of SSL it may be sort of possible, but since you don't get raw socket support it's going to be a non-compatible kludge, barring some extremely clever and probably not at all cross-platform hack.
I've taken a look at your site, and I see a couple of possible problems with your scheme.
First off, the master password thing makes me nervous. If your master password is compromised, then all your previous passwords are compromised. I think that there are ways to mitigate this risk, by using salts. I'm not sure about this, but it's my gut feel.
Second, to your question. You probably do not want to use CRC32 to hash the input. When you take MD5(masterpw + siteurl) = sitepw, you're relying on the fact that if someone gets your sitepw, they still won't be able to recover the masterpw even if they know the url.
It's a little late, and despite my nick, I'm a bit rusty on the mathematical details at the moment. My inclination is that CRC32 isn't a good idea for absolute security. Reply if you want to chat about this off-thread, and I'll get in touch.
Slightly OT, but for hiding mailto links
by
WoTG
·
· Score: 2, Informative
I've recently discovered (or maybe I saw it on another/. article...) this nifty
javascript "mailto" encoder. It creates drop in javascript that obliviates the need to put email addresses in cleartext on a public webpage. The JS created mailto links work just like they should. Yes, spam bots could learn to read javascript, but, they won't for a while...
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?
What's the point? It is useful to encrypt the data in transit, even if you don't know who it's going to -- then at least there's only one party who can steal your card number, instead of a dozen. Beyond that, if you connect via SSL, and your browser doesn't complain about an invalid certificate, you know a couple of things:
The site has a certificate from a "trusted" certificate authority. While the level of verification that these CA's do isn't all that high, and they're not necessarily people you would trust a huge amount, you probably can trust that they've done some basic checking up on the site. The main thing is that they know who the legal entity is who paid for the certificate, which means that in the case of fraud, you have a better chance of being able to track the site owner down.
The web site your browser thinks its connected to is the same one listed in the certificate. This means that if you think you're connected to a site you consider trustworthy (for whatever reason), chances are very high that you actually are connected to that site and are not being spoofed by someone who's hijacked your connection.
So, there *is* value in that little lock on your browser window, even if the security isn't iron-clad. Note that the recent spate of Paypal hoax sites that ask for CC# and PIN do NOT use SSL. Why not? Because it's too hard, and too risky, for them to try to obtain a valid cert.
And can someone explain to me again why some people still persist with giving their credit card numbers over the phone "because its more secure"?;
Because it is! Under most circumstances anyway. Assuming you called them, and you looked up their phone number in some trustworthy place (like the phone book), then the odds that you're giving your credit card number to someone else are pretty small. Basically, the only way your number could be stolen would be if someone were tapping your line*. Not that wiretaps are all that tough to implement, but they're not that common, either, and more importantly they're not very easy to automate.
Compare that to sending your CC# to a web site. How could that be hijacked? Well, to start with, your machine could be trojaned (worms can quicky infect millions of machines), so the simple act of typing your number in compromises it. Next, assuming no SSL, the data will go in the clear over better than a dozen network hops, more often two dozen, before arriving at the destination. The number can be copied anywhere en-route. Thanks to DNS spoofing, router hacks, compromised proxies, etc., that destination may not even be where you think it is.
And computer-based CC# theft is eminently automatable. Packet sniffers can collect and report anything that appears to look like a number. Trojans can quietly search your whole machine looking for numbers. Faked sites can be set up to collect bunches of numbers.
The fact that computer-based CC# theft can be automated means that the rewards are higher, i.e. it's worth the effort. It's also less risky: the scanning tools can send the data to electronic dead drops on hacked machines so that with a little care the attacker is almost completely untraceable (until he tries to *use* the numbers, but that's a separate issue). Contrast that with the effort and risk involved in tapping telephones.
Until the ideas actually sink in at a deep cultural level, we will continue to have all manner of stupid and contradictory actions from people who don't have the time to understand how all of this works.
But don't denigrate useful security measures just because *you* don't understand how they work!
* Note that there is another obvious attack against phone-based CC# delivery: call re-routing. Someone with the ability to re-program the exchanges could get your call sent elsewhere. Again, though, this is labor-intensive and risky, and it requires a high level of access into telco systems, which is not easy to obtain (unlike 20 years ago).
-- Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Implement RSA in java
by
autopr0n
·
· Score: 3, Informative
public static byte[] encrypt(byte[] enKey, byte[] data) throws Exception{
//make sure our int is unsigned; //this means -45 --> 45 or whatever, as opposed // to not being digital signed with a public key crypto system:) byte unsigned_data[] = new byte[data.length+1]; unsigned_data[0] = 0x7f; for(int i = 0; i < data.length; i++){ unsigned_data[i+1] = data[i]; }
KeyFactory kf = KeyFactory.getInstance("RSA"); RSAPublicKey k = (RSAPublicKey)kf.generatePublic(new X509EncodedKeySpec(enKey)); BigInteger T = new BigInteger(unsigned_data); return T.modPow(k.getPublicExponent(), k.getModulus()).toByteArray(); }
//your welcome
-- autopr0n is like, down and stuff.
Re:JavaScript RULEZ!!1!
by
oGMo
·
· Score: 2, Informative
JavaScript is pretty elegant... if you want a more "full-fledged" language that has similar elegance, even more simplicity/grace, and more libraries, try ruby. Don't let a few surface features or initial impressions fool you into thinking it's anything like Perl (or Python). It would probably make a good beginner language; it certainly makes a great "advanced" language.;-)
--
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Rather then passing hash(password) send in hash(salt + password), where hash is a random string sent by the server. The server then compares the sent value to it's own hash of salt + password. If you don't want to deal with sessions, you could simply change the salt every hour or 5 minutes or whatever.
You could also do hash(salt + hash(password)), that way you don't need to keep the password in the DB.
Simple script security
by
sdsykes
·
· Score: 3, Informative
This is a similar javascript utility aimed at encrypting your entire web page. It is used for putting secure content on an open access web server. You can only view the content if you happen to know the key. It's very cool, and has been around for a long time. Secure, small and fast.
Re:Similar techniques are in use already
by
metalpet
·
· Score: 2, Informative
Yeah, home pages are good. Someday I'll write one.
In the meanwhile, my original page has been mirrored at this page by a kind soul.
The pajhome source code is arguably prettier than mine, and should almost always be used, rather than mine.
To my defense, mine was developed and works under netscape 2.0, which probably makes it the first md5 implementation in javascript ever.
I have a nagging feeling pajhome's version requires at least NS3/IE3, although I haven't checked that.
At the time, after I benchmarked it and realized how slow it was to run at the time, I had serious second-thoughts about its usefulness (the 7 hashes test on the page above would take 10 to 15 seconds to run on some very reasonable desktop hardware.)
Things have gotten better, both on the CPU and the javascript speed front, and it does make a lot of sense now to use it for password submissions if you don't want to take the extra cost of SSL.
Slashdot Mirror
There are more than a few out there already (not surprisingly!):
RSA Crypto-J
BouncyCastle
Cryptix
Flexiprovider
There's a bunch more too - just google for them.
Some of these are free, some are Free and some are neither. Personally, I've written banking software using the RSA libs (I tried to get use BouncyCastle but management didn't like the name!).
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
For quite a good long time now (in computer terms that is) Yahoo has been doing this same thing. If you log-in without entering SSL mode, you need to have javascript enabled in your browser so that the script can MD5-encrypt your password.
Despite the whole client-side-encryption advantage, I dislike how much easier it would be to perform a man-in-the-middle, or a number of other exploits. I will admit, however, that I am quite concerned with the prospect of honeypot SSL sites, designed to steal info, but I think the former is more likely. So, for now, I am sticking with SSL. Maybe in conjunction with SSL, this would make an ideal solution. Of course, SSH would be even better...
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Hushmail uses a Java applet to encrypt mail - maybe you could get your grandmother to use that. There are other Java crypto implementations, such as Cryptix. Packaging one as an applet shouldn't be too hard.
I'm already seeing people mix the two up in this thread, let's set this down straight:
JavaScript/ECMAScript: Untyped yucky scripting language developed by Netscape (IIRC) and built into browsers so you can have image rollovers.
-- has nothing whatsoever to do with --
Java: OO, multi-threaded, multi-platform language used occasionally on websites as applets, but much more frequently on the back end for app servers and the like.
This has been a public information posting.
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
The algorithm Javascrypt implements is absolutely useless for what you're talking about. AES is a symmetric encryption algorithm, which means that if you're going to send the data to some server using Javascrypt, at some point you need to communicate the key. If you send the key with the data (not to mention the .js for decryption), you've just royally wasted your time. This could only be useful if you agree to a key in advance using some non-internet connection method, in which case you're not going to go with a "cheap ass" encyption technique like this.
(I do not mean to disparage the Javascrypt work, it's good stuff. But it's more useful to introduce people to encryption then for any practical use.)
The genius of asymmetric encryption is that you can negotiate a secure connection without compromising it; it is not immediately obvious this should be possible and I consider it one of the larger mathematical results of the previous century. Extensions of that work have resulted in the ability to "sign" the keys during exchange. None of this applies to symmetric encryption because you have to agree on a key directly with the sender. (You could in theory still provide a third-party affirmation of the validity of a given key with symmetric encryption but not without giving the third party the key, which is undesirable. With asymmetric encryption the third party can sign a public key without knowing the private key that generated it, so even though Verisign signs your key it does not mean that Verisign can read through the resulting encrypted connection.)
A lot of people seem to be laboring under this misconception. Javascrypt is a neat toy and a valuable educational tool. It is not and can not replace SSL or the SSL layer of the browser. If someone wants to implement a version of SSL it may be sort of possible, but since you don't get raw socket support it's going to be a non-compatible kludge, barring some extremely clever and probably not at all cross-platform hack.
I've taken a look at your site, and I see a couple of possible problems with your scheme.
First off, the master password thing makes me nervous. If your master password is compromised, then all your previous passwords are compromised. I think that there are ways to mitigate this risk, by using salts. I'm not sure about this, but it's my gut feel.
Second, to your question. You probably do not want to use CRC32 to hash the input. When you take MD5(masterpw + siteurl) = sitepw, you're relying on the fact that if someone gets your sitepw, they still won't be able to recover the masterpw even if they know the url.
It's a little late, and despite my nick, I'm a bit rusty on the mathematical details at the moment. My inclination is that CRC32 isn't a good idea for absolute security. Reply if you want to chat about this off-thread, and I'll get in touch.
I've recently discovered (or maybe I saw it on another /. article...) this nifty
javascript "mailto" encoder. It creates drop in javascript that obliviates the need to put email addresses in cleartext on a public webpage. The JS created mailto links work just like they should. Yes, spam bots could learn to read javascript, but, they won't for a while...
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?
What's the point? It is useful to encrypt the data in transit, even if you don't know who it's going to -- then at least there's only one party who can steal your card number, instead of a dozen. Beyond that, if you connect via SSL, and your browser doesn't complain about an invalid certificate, you know a couple of things:
So, there *is* value in that little lock on your browser window, even if the security isn't iron-clad. Note that the recent spate of Paypal hoax sites that ask for CC# and PIN do NOT use SSL. Why not? Because it's too hard, and too risky, for them to try to obtain a valid cert.
And can someone explain to me again why some people still persist with giving their credit card numbers over the phone "because its more secure"?;
Because it is! Under most circumstances anyway. Assuming you called them, and you looked up their phone number in some trustworthy place (like the phone book), then the odds that you're giving your credit card number to someone else are pretty small. Basically, the only way your number could be stolen would be if someone were tapping your line*. Not that wiretaps are all that tough to implement, but they're not that common, either, and more importantly they're not very easy to automate.
Compare that to sending your CC# to a web site. How could that be hijacked? Well, to start with, your machine could be trojaned (worms can quicky infect millions of machines), so the simple act of typing your number in compromises it. Next, assuming no SSL, the data will go in the clear over better than a dozen network hops, more often two dozen, before arriving at the destination. The number can be copied anywhere en-route. Thanks to DNS spoofing, router hacks, compromised proxies, etc., that destination may not even be where you think it is.
And computer-based CC# theft is eminently automatable. Packet sniffers can collect and report anything that appears to look like a number. Trojans can quietly search your whole machine looking for numbers. Faked sites can be set up to collect bunches of numbers.
The fact that computer-based CC# theft can be automated means that the rewards are higher, i.e. it's worth the effort. It's also less risky: the scanning tools can send the data to electronic dead drops on hacked machines so that with a little care the attacker is almost completely untraceable (until he tries to *use* the numbers, but that's a separate issue). Contrast that with the effort and risk involved in tapping telephones.
Until the ideas actually sink in at a deep cultural level, we will continue to have all manner of stupid and contradictory actions from people who don't have the time to understand how all of this works.
But don't denigrate useful security measures just because *you* don't understand how they work!
* Note that there is another obvious attack against phone-based CC# delivery: call re-routing. Someone with the ability to re-program the exchanges could get your call sent elsewhere. Again, though, this is labor-intensive and risky, and it requires a high level of access into telco systems, which is not easy to obtain (unlike 20 years ago).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
import java.io.*;
//make sure our int is unsigned;
//this means -45 --> 45 or whatever, as opposed
// to not being digital signed with a public key crypto system :)
import java.util.*;
import java.security.*;
import java.security.interfaces.*;
import java.security.spec.*;
import javax.crypto.*;
import javax.crypto.interfaces.*;
import javax.crypto.spec.*;
import java.math.*;
....
public static byte[] encrypt(byte[] enKey, byte[] data) throws Exception{
byte unsigned_data[] = new byte[data.length+1];
unsigned_data[0] = 0x7f;
for(int i = 0; i < data.length; i++){
unsigned_data[i+1] = data[i];
}
KeyFactory kf = KeyFactory.getInstance("RSA");
RSAPublicKey k = (RSAPublicKey)kf.generatePublic(new X509EncodedKeySpec(enKey));
BigInteger T = new BigInteger(unsigned_data);
return T.modPow(k.getPublicExponent(), k.getModulus()).toByteArray();
}
//your welcome
autopr0n is like, down and stuff.
JavaScript is pretty elegant... if you want a more "full-fledged" language that has similar elegance, even more simplicity/grace, and more libraries, try ruby. Don't let a few surface features or initial impressions fool you into thinking it's anything like Perl (or Python). It would probably make a good beginner language; it certainly makes a great "advanced" language. ;-)
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Rather then passing hash(password) send in hash(salt + password), where hash is a random string sent by the server. The server then compares the sent value to it's own hash of salt + password. If you don't want to deal with sessions, you could simply change the salt every hour or 5 minutes or whatever.
You could also do hash(salt + hash(password)), that way you don't need to keep the password in the DB.
autopr0n is like, down and stuff.
Maybe, you may find this tutorial useful: CRC and how to Reverse it.
Tired of free ipod spam sigs? Opt ou
http://fetchyahoo.sourceforge.net/
http://yahoopops.sourceforge.net/
This is a similar javascript utility aimed at encrypting your entire web page. It is used for putting secure content on an open access web server. You can only view the content if you happen to know the key. It's very cool, and has been around for a long time. Secure, small and fast.
In the meanwhile, my original page has been mirrored at this page by a kind soul.
The pajhome source code is arguably prettier than mine, and should almost always be used, rather than mine.
To my defense, mine was developed and works under netscape 2.0, which probably makes it the first md5 implementation in javascript ever.
I have a nagging feeling pajhome's version requires at least NS3/IE3, although I haven't checked that.
At the time, after I benchmarked it and realized how slow it was to run at the time, I had serious second-thoughts about its usefulness (the 7 hashes test on the page above would take 10 to 15 seconds to run on some very reasonable desktop hardware.)
Things have gotten better, both on the CPU and the javascript speed front, and it does make a lot of sense now to use it for password submissions if you don't want to take the extra cost of SSL.