Thank you point me out. Definitely, I need to implement PBKDF2 (and add salt to password). I planning this, but weekend is too short and finally I just put SHA256 for key derivation.
But, until you describe, I do not recognize what the principal difference between hash and password based key derivation function, thanks.
I assume you know that the reason you add a salt is to prevent rainbow table attacks. Without a salt, if someone obtains the hash then they need to just run it through a single rainbow table and with very high probability, obtain the password.
A SHA{1,2,3,128,256,512} hash is very VERY VERY fast. So fast, in fact, that an attacker who has the hash could easily run through all 8 character passwords given a few GPU machine clusters.
PBKDF2 is very much like a SHA hash, but it is repeated over and over. Instead of just salt||SHA1(password||salt) you compute salt||SHA1(SHA1(SHA1(SHA1(SHA1(password||salt))))). This makes it so an attacker with the hash has to do much more work in order to brute force the password.
Now, that's not exactly how it works, but just read the wikipedia article for that.
What you described is essentially PBKDF1, which is similar to PBKDF2, but only supports a fixed output key length. It's also a decent option; just not as flexible as PBKDF2.
I was describing it in order to explain the general idea; not to explain the exact algorithm. The wikipedia article does a better job at that than I could do, but since he asked the question after the link to the wikipedia article I assumed that what he wanted was a simple explanation of what the difference is between just SHA(password) and PBKDF(password).
Yes, I will install ssl cert in future (at least self signed), understand the risk. Standalone bookmark is great idea, but I am not sure if I can fit script to 2048 bytes. Maybe, I'll make html5 cache manifest to avoid network access.
Even if you could somehow minify all of AES into a bookmarklet, you'd still lose any time any page this ran from requested HTML or JS from a non-HTTPS link, since any of those requests could poison the runtime.
Not in and of itself. Google runs SPDY over SSL, just as they also run HTTP over SSL (HTTPS). It's the SSL that makes it secure. Once you're running one protocol over SSL, you might as well run all of them over SSL.
The basic problem here is that JS is too dynamic to ensure this type of security. Any script running on the page can rebind any value, monitor or trigger any event, or a number of other things. Without SSL or similar, an attacker can inject any script they want into the page.
The simplest variant of such an attack would be a script that replaces your AES function with a ROT13 or other useless cipher. There are variations on this theme, and in the end it's impossible to defend against all of them.
It doesn't help in this case, since an attacker can just insert plain old JS. Caja (and similar things) only help for code you can actually put through the Cajoler.
It's still a good, if imperfect, solution for other use-cases.
Don't do your self the disservice of self-signed - you can get a free cert from startssl.
The CA landscape has changed.... what used to be expensive and required a lot of paperwork is getting cheap/free, and CAs are pushing "Extended validation" certificates and whatnot (the ones that turn your browser bar green, etc....)
Just hit up startssl and get a real certificate... it's that easy. No strings attached.
(Repeating this because I ignored it for about a year until actually checking it out and realizing I'd been an idiot)
ALSO
Given the single utility of this - just inline the scripts you need and avoid the request overhead. You can probably strip out all the functions you don't need to minimize the load time. You could offer a minimized version as well....
Thank you for advice about cert service! Awesome. Will request SSL cert right now.
I consciously left scripts uncompressed, so anybody can look what going on behind the scene. Also, I'll publish source code on github as soon as clean it up. Then I make compressed version.
The "other" reason to avoid a self signed cert is that a self signed cert still leaves your users open to a MITM attack. If your goal is to avoid a MITM, a self signed cert gives you nothing but more configuration lines in your webserver config.
Sure, but on modern browsers only (utilizing html5 file API). I am thinking about implementing RSA private key generation and online public key registry in future.
That's also not a secure way of generating an AES key; those crypto keys can be cracked quickly. The problem you're trying to solve is the entire reason for PBKDF2.
