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.
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.
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.
I've always thought that a Java implementation of public key encryption would be useful.
For example, I'd like to be able to put up a page on my web site containing a Java applet with my embedded public key.
That way I could finally remove my grandmother's AOL account from the exception list, the last obstacle standing between me and my "all incoming mail must be either signed by somebody I trust or encrypted with my public key" procmail rule.
Requiring the sender to use their own CPU cycles to encrypt messages is a classic variation on the "micropayments" approach to reducing spam volumes...
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"
I've been poking around trying to generate Web-site passwords by hashing the hostname and a master password, and I've come up with this bookmarklet which takes the first 8 chars of the hex representation of the MD5 hash.
This means you only have to remember one master password, and each site you register for gets its own unique password - instead of using the same throwaway password all over so you've given your whole online identity to each site's admins...
I've been meaning to find a crypto guy to ask if I could just use CRC32 to hash the input string, since MD5 is too much Javascript to bookmark in IE. I know it's not a secure way to checksum a file, but given a CRC32 hash and part of the input, can you recover the other part? Anybody?
Similar techniques are in use already
by
gusnz
·
· Score: 5, Interesting
Have a look at Yahoo Mail's login page (you may have to log out of Yahoo services completely to see it). If you view source on that, you'll see:
/*
* A JavaScript implementation of the RSA Data Security, Inc. MD5 Message
* Digest Algorithm, as defined in RFC 1321.
* Copyright (C) Paul Johnston 1999 - 2000.
* Updated by Greg Holt 2000 - 2001.
* See http://pajhome.org.uk/site/legal.html for details.
*/
They're using a JS implementation of the MD5 algorithm to calculate client-side hashes of user passwords before form submittal.
It's definitely an interesting approach especially of a site that size, when you look at how much server CPU usage a full SSL login connection would take. And in the event that someone compromises a secure server, your password wouldn't be available to the attacker, only the hash.
Plus, JS is free to implement (unlike a SSL cert) so hopefully if this technique catches on, more mom-n-pop sites will wind up using it instead of a totally unencrypted login connection.
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.
For example, I'd like to be able to put up a page on my web site containing a Java applet with my embedded public key.
That way I could finally remove my grandmother's AOL account from the exception list, the last obstacle standing between me and my "all incoming mail must be either signed by somebody I trust or encrypted with my public key" procmail rule.
Requiring the sender to use their own CPU cycles to encrypt messages is a classic variation on the "micropayments" approach to reducing spam volumes...
I do not deploy Linux. Ever.
I've been poking around trying to generate Web-site passwords by hashing the hostname and a master password, and I've come up with this bookmarklet which takes the first 8 chars of the hex representation of the MD5 hash.
This means you only have to remember one master password, and each site you register for gets its own unique password - instead of using the same throwaway password all over so you've given your whole online identity to each site's admins...
I've been meaning to find a crypto guy to ask if I could just use CRC32 to hash the input string, since MD5 is too much Javascript to bookmark in IE. I know it's not a secure way to checksum a file, but given a CRC32 hash and part of the input, can you recover the other part? Anybody?
It's definitely an interesting approach especially of a site that size, when you look at how much server CPU usage a full SSL login connection would take. And in the event that someone compromises a secure server, your password wouldn't be available to the attacker, only the hash.
Plus, JS is free to implement (unlike a SSL cert) so hopefully if this technique catches on, more mom-n-pop sites will wind up using it instead of a totally unencrypted login connection.
<!-- DHTML / JavaScript menu, popup tooltip, Ajax scripts -->