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.
Well, you could just start up a cert org for producing Javascrypted certificates. Being a certification organization is primarily a trust issue. Open up your certification procedures, i.e. do you check an applicant's credit card, do you retain copies of drivers license, etc, or do you only require an email address, etc. Get yourself backed by an org like Truste, who will vouch for your integrity, etc. Then lobby for Microsoft, Netscape, and Mozilla to accept certs issued by you as valid, and you're ready to go. The technical issues behind creating a certificate are easy. If you want to read more into this, I suggest Googling for the Java 2 certification production scheme, etc. You can probably write up a quick scheme to create certs, sign them with your key, etc. After all, what is a cert? It's simply a document saying "Yup, site ______ can be trusted", signed with your private key. Then any MS, Netscape, or Mozilla client can simply validate the certificate using a widely available public key.
I've often wondered a little about the demand for ultra high powerd crypto for e-commerce. 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?
I seem to recall a quote about armoured cars being used to deliver a package from someone living under a bridge to someone living in a cardboard box.
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"?
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. Hopefully it'll happen soon, right?
I think that is the entire point. Some businesses only put just enough effort into anything to make sure they won't get sued.
Vendors of e-commerce packages come to mind. Their software makes just enough effort so that if anything goes wrong it's going to happen on the end-systems and is therefore be the fault of operator / client / user.
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.
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.
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.
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,
neat piece of work
by
Anonymous Coward
·
· Score: 2
this means that i can encrypt my webmail and the recepient can view it tooo gr8!
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
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"
Javascript insecurity
by
Anonymous Coward
·
· Score: 3, Interesting
Since javascript has to be the second biggest backdoor into your computer since MS Windows, it never ceases to amaze me that people can take this stuff seriously.
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;
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.
I've used javascript cryptography routines before, once in a php project for authentication, used javascript to generate an md5 hash of the password and sent the hash over http.
I considered it a hack, but it's what the client wanted, and who am I, the developer, to question the client's motives? Cheap bastard, didn't want to pay for an SSL cert. Just hope no one passes the hash.;)
I don't see why this is a problem for *hiding passwords*, but the hash can be intercepted and replay attacks can be done. What you should do would be to have the client request a single-use time-limited challenge nonce from the server and hash the password together with it, and compare with the original.
Javascript not just for Clients
by
yomahz
·
· Score: 3, Interesting
There are a number of servers that support server-side javascript. I recently had a project where a remote office needed to communicate with a servlet based webpage using RC4 ecnrypted parameters.
The remote office didn't know much programing so I wrote a RC4 and base64 implementation in Javascript for them to implement server side.
-- "A mind is a terrible thing to taste."
Nice approach
by
randall_burns
·
· Score: 3, Interesting
This stuff is nice because Javascript is a very accessible language(i.e. lots of people know it). This is stuff that can be maintained in situations where other approaches aren't really practical.
I'm also glad to see folks doing more with the capabilities within a browser. The folks that are taking this the furthest that I've seen are the folks at Technical Pursuit.
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?
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.
A few years ago
Me: I know Java!
Silly person: Cool, you can make applets!
A few less years ago
Me: I know Java!
Silly person: Cool, you can do DHTML!
Now
Me: I know Java!
Silly person: So you can do encryption!
Am I the only one...
by
eviltypeguy
·
· Score: 4, Funny
Am I the only one that read the headline as:
"Java's Crypt"
Java dead already? Odd...
I thought, geez the Slashdot Trolls really *have* taken over...
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...
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.
It's just weakly typed.
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.
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.
Re:Similar techniques are in use already
by
BlueFall
·
· Score: 2, Interesting
That's cool to know, but I don't think that this is true:
And in the event that someone compromises a secure server, your password wouldn't be available to the attacker, only the hash.
If you look at the code on the site, they have a 'challenge' value that is appended to the hash of the password, so to calculate the challenge response you need both the 'challenge value' (a.k.a. a nonce) and your password. The server needs the same thing. I think that this same technique is used in APOP.
The only way that they wouldn't need some shared secret is if you used some sort of asymmetric signing protocol, but then key distribution is a problem...
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.
Why this is useful
by
EmCeeHawking
·
· Score: 3, Interesting
I see a lot of posts here wondcering how this is useful and why not just use PGP.
I can't imagine people really trust PGP anymore. No longer open source, no longer affiliated with Phil Zimmerman... and his statement when he left was scary.
For those who don't know, Phil stated when he left that every PGP product released while he was there contained no hidden back doors. Knowing that companies like PGP were being pressured, it makes me think the creative differences were them wanting to build something in that he thought shouldn't be in.
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...
Re:JavaScript RULEZ!!1!
by
S.Lemmon
·
· Score: 2, Interesting
The main problem is it's *almost* elegant, but not quite 100% there - in actualy use it always seems like you need some ugly half-assed hack to do something that should be simple.
For example, say in a form you want to validate a field as soon as the person enters it (i.e. they type a bad value and it returns focus to the field). Sounds simple right? Just trap the onblur event, test the field, and call focus() if it fails.
Not so... most browsers will ignore focus called from within onblur (because the "blur" happens after the event fires, and you can't stop it). You wind up with the silly, messy hack of setting a timer to call focus() a few milliseconds later. Really, this makes onblur almost useless for the main thing you'd expect to use it for!
It's quirks like this that makes you pull your hair out trying to do anything serious with javascript. I sometimes wonder if those setting the standards have actually ever eaten their own dog food (as the Mozilla folks like to say).
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
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...
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.
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:Implement RSA in java
by
Anonymous Coward
·
· Score: 2, Funny
//your welcome
What about "my" welcome? If you leave my welcome alone, I'll leave your welcome alone.
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.
Cool, but it needs a net connection
by
CurbyKirby
·
· Score: 2, Interesting
Stealing and modifying some RC4 code, I made a self-contained Javascript/PHP CipherSaber encoder/decoder.
Boring I know, but at least it can create self-decrypting HTML files where the ciphertext and decryption code is all self-contained. With such output, any* JS-enabled browser can decrypt the file without a net connection. Here's a sample (use password "test" and 1 loop). This idea can be modified to fit almost any encryption scheme; RC4 just seemed like a good mix of security and extreme ease of implementation at the time.
* This is almost guaranteed NOT to work on Safari in Mac OSX. It works on recent Firebird builds under Windows XP and RedHat 9 (and probably other things as well).
--
--
"Extra Anus Kills Four-Legged Chick" -- Headline
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.
I thought MD5 was cracked?
Useful teaching tool
by
ca1v1n
·
· Score: 4, Interesting
Schneider's javascript Rijndael implementation makes a great teaching tool, because it's so easy to modify it to show intermediate steps. Sure, you can do this in any other language, but it's especially compact in javascript, and anyone who has ever programmed in ANY modern language can read javascript, which cannot be said of plenty of other languages. For my architecture class we had to implement Rijndael with synthesizable modules, and that implementation saved us countless hours, because it was so easy to tweak things in the javascript implementation that we could often save time by deliberately introducing bugs into the reference implementation and seeing if it had familiar effects. Anyone who's ever used FPGA Advantage probably knows how much of a pain in the ass it can be debugging with that alone.
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.
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?
Similar thing for Flash ActionScript
by
dodell
·
· Score: 2, Interesting
I created a similar thing for Flash ActionScript called ActionCrypt; although it's still in progress. You might want to check it out; Javascript and ActionScript are very similar (as they're both based on the same syntax).
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 means that i can encrypt my webmail and the recepient can view it tooo gr8!
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 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.
Since javascript has to be the second biggest backdoor into your computer since MS Windows, it never ceases to amaze me that people can take this stuff seriously.
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.
I've used javascript cryptography routines before, once in a php project for authentication, used javascript to generate an md5 hash of the password and sent the hash over http.
;)
I considered it a hack, but it's what the client wanted, and who am I, the developer, to question the client's motives? Cheap bastard, didn't want to pay for an SSL cert. Just hope no one passes the hash.
There are a number of servers that support server-side javascript. I recently had a project where a remote office needed to communicate with a servlet based webpage using RC4 ecnrypted parameters.
The remote office didn't know much programing so I wrote a RC4 and base64 implementation in Javascript for them to implement server side.
"A mind is a terrible thing to taste."
I'm also glad to see folks doing more with the capabilities within a browser. The folks that are taking this the furthest that I've seen are the folks at Technical Pursuit.
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?
A few years ago Me: I know Java! Silly person: Cool, you can make applets! A few less years ago Me: I know Java! Silly person: Cool, you can do DHTML! Now Me: I know Java! Silly person: So you can do encryption!
Am I the only one that read the headline as:
"Java's Crypt"
Java dead already? Odd...
I thought, geez the Slashdot Trolls really *have* taken over...
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
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"
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.
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 -->
I see a lot of posts here wondcering how this is useful and why not just use PGP.
I can't imagine people really trust PGP anymore. No longer open source, no longer affiliated with Phil Zimmerman... and his statement when he left was scary.
For those who don't know, Phil stated when he left that every PGP product released while he was there contained no hidden back doors. Knowing that companies like PGP were being pressured, it makes me think the creative differences were them wanting to build something in that he thought shouldn't be in.
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...
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...
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.
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.
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
Stealing and modifying some RC4 code, I made a self-contained Javascript/PHP CipherSaber encoder/decoder.
Boring I know, but at least it can create self-decrypting HTML files where the ciphertext and decryption code is all self-contained. With such output, any* JS-enabled browser can decrypt the file without a net connection. Here's a sample (use password "test" and 1 loop). This idea can be modified to fit almost any encryption scheme; RC4 just seemed like a good mix of security and extreme ease of implementation at the time.
* This is almost guaranteed NOT to work on Safari in Mac OSX. It works on recent Firebird builds under Windows XP and RedHat 9 (and probably other things as well).
--
"Extra Anus Kills Four-Legged Chick" -- Headline
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?
Schneider's javascript Rijndael implementation makes a great teaching tool, because it's so easy to modify it to show intermediate steps. Sure, you can do this in any other language, but it's especially compact in javascript, and anyone who has ever programmed in ANY modern language can read javascript, which cannot be said of plenty of other languages. For my architecture class we had to implement Rijndael with synthesizable modules, and that implementation saved us countless hours, because it was so easy to tweak things in the javascript implementation that we could often save time by deliberately introducing bugs into the reference implementation and seeing if it had familiar effects. Anyone who's ever used FPGA Advantage probably knows how much of a pain in the ass it can be debugging with that alone.
WARNING: there is a trojan on your
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.
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?
I created a similar thing for Flash ActionScript called ActionCrypt; although it's still in progress. You might want to check it out; Javascript and ActionScript are very similar (as they're both based on the same syntax).
www.sitetronics.com/wordpress