How to simply encode and decode a string variable - javascript

I need to simply encode a string variable (my api key) so that is not easily readable by human eyes, I need it to easily decode back to exactly the same initial string. What is the standard practical and fast (less computing on the user side) way to do this?
Many thanks in advance!

If it doesn't have to be super-secure, Base64 encoding is always handy:
http://www.webtoolkit.info/javascript-base64.html

Everything you can do to obfuscate information on the client implies that you include the code for de-obfuscation right next to it.
So… apart from adding one extra step for your program (and the hypothetical attacker), you gain nothing. Well, not much anyway.
If your API key is secret, keep it on the server and let the server do the work through HTTP requests.

You could try a Javascript Obfuscator to either encode your whole script or parts. Not an absolute solution but a start to protecting your code.

you could use a 3rd party base64 encoder library: http://ostermiller.org/utils/Base64.html

Is this secret information or not?
If it is secret, you need a real encryption library and some deep thinking too make sure your secret is kept secret. I would seriously consider never sending any secret to the browser.
If this isn't secret and you just need need to send this over the URL without it getting borked then escape()/unescape() are what you are looking for.

Related

something better than base64 to encode data that doesn't take up too much processing power

I have a web site in which users can add multiple items and sometimes the URL can be long. I thought by using base64 encoding, I'd pass the URL along but it contains a slash which I use to separate items because my web server cannot handle path names (anything between 2 slashes) longer than 255 characters or I'd get a 403 error.
Is there another way I can encode data quickly in javascript so that theres a 0% chance that a slash will occur in the result?
I'm looking for something not too processor intensive and if possible, I want to go for something better than character swapping.
I will understand if I need to visit a library, but the only encoding built-in to javascript (to my knowledge) is base64 (via the atob function) and I want something different.
I also want to be able to make the solution work with older web browsers as well.
What you need is encodeURIComponent, which is part of the javascript spec and automatically included in all javascript environments
var url = 'example.com/someextenstion/' + encodeURIComponent(theString);
There are many ways to address this but one of the simplest is going to be to take an implementation of atob and btoa and modify it to use a - instead of a / when encoding. You'll have to rename the functions so they don't mask the standard function, but here's some JavaScript source code that does the trick: github. In that particular implementation just replace the / in _ALPHA with a - (or any character of your choosing).
It might be faster to just do as Amit suggests: use the standard functions and do a quick string replace of / on conversion: str.replace(/\//g,'-'); and perform the reverse on decoding, but it doesn't seem like performance will be critical in this application.

How to encode/decode URL parameters in javascript?

Before anyone jumps in and says, "Oh!! that's a bad idea", I know it is.
I want to keep both the key and value in the query string to be not easily visible to the end user.
I have something like this google.com/?category=textile&user=user1
I need to make it unintelligible like this: google.com/?kasjdhfkashasdfsf32423
Is there any way to achieve this in javascript. I have already seen this
I have already seen this
and this.
but I don't think encoding will solve the problem. Also, this code is entirely in client side. I know that it is not secure but I just need this is a naive, weak defense.
Please help.
Edit
I apologize if my question was not clear earlier.
The URL google.com/?category=textile&user=user1 is being passed on from a different application.
The values passed in the query string directly controls what is being displayed to the user. As is, anyone with no technical knowledge can easily change the value and view the data corresponding to a different category or user. I need to make this unintelligible so that it is not obvious. If a user is a techie and figures out the encryption used, then it is fine. I need a stop-gap solution till we have a better architecture in place
You can use base64. Javascript has native functions to do that :
alert(btoa("category=textile&user=user1")); // ==> Y2F0ZWdvcnk9dGV4dGlsZSZ1c2VyPXVzZXIx
and to reverse it :
alert(atob("Y2F0ZWdvcnk9dGV4dGlsZSZ1c2VyPXVzZXIx")); // ==> category=textile&user=user1
Be careful to read the doc if you have unicode strings, it's a little different : https://developer.mozilla.org/en-US/docs/Web/API/Window.btoa
If you don't looking for serious strong crypto, you can use ROT13:
http://en.wikipedia.org/wiki/ROT13
This is enough for slightly obfuscate keys/values in the your URLs.

one way SHA1 hash javascript implementation?

I have a server that is not using SSL, so I'm trying to find a way to secure the data being passed to the server. My first thought was jCryption, but it is not exactly what I need. So what I decided is that I could just pre-hash the password and send it to the server for comparison. So my question is, is there a sha1 utility that can be used for password verification purposes with PHP?
Try the Stanford Crypto library. It's pretty comprehensive but if you just need a single hashing function you can extract it from the core (it has sha1 and 256).
Refer This
You shouldn't be using SHA1 to do your hashing anymore, since it's been broken for a while. Try SHA256.
I think that's what you're looking for: http://phpjs.org/functions/sha1:512

encrypting data on client-side via html5 javascript

im building a web app in html5.. basically a form with a time counter and questions and answers.
im looking for a way that the user cannot change the score (that is calculated from the time took to answer the question) via browser debugger or etc.
encrypting the raw data sounds like an options.. but when the data is at dom, the user can change it.
i added some "time checking" in server side.. but still i would prefer some client side protection as well.
any suggestions? thanks
I'm no web pro, but I'd say just stick all the validation on the server side. From what I know about people exploiting MMORPGs, there is always a way to access/change client side data.
What you're asking for is impossible. No matter how you implement it, the user can use debugging tools to alter how the code runs in their browser - or, ultimately, just generate the HTTP POST request themselves, independent of your code.
Well, since you're saying you're using html5, why don't you just use the storage support?
e.g:
var store = sessionStorage.question= new Array();
store[0]="10s";
store[1]="5s";
Now just set that programmatically! It will last for the whole session
Put that in a file and import it and the better-than-average user wont know where to look!
You can also check This Link for a more robust solution
As Nick says, a determined user will be able to get round any encryption scheme you use on the client machine. At most you can make it difficult for them to break. You need to do two things, 1) encrypt so as to make tampering difficult and 2) try to detect any tampering that does occur.
I don't know what is available off the shelf for Javascript, if available then use AES for encryption and HMAC to detect tampering. If you have to write your own then use RC4 for encryption (not as strong as AES but much simpler to code) and a checksum to detect tampering.
One thing you can do to make it more difficult for an attacker to find your encryption key and HMAC key is not to store them in one place. Have two arrays such that the real key is array1 XOR array2. That way the actual key is not explicitly in code anywhere.

Why not eval() JSON?

As far as I know it is considered bad practice to eval() JSON objects in JavaScript, because of security. I can understand this concern if the JSON comes from another server.
But if the JSON is provided by my own server and is created using PHP's json_encode (let us assume it is not buggy), is it legitimate to simply use eval() to read the JSON in JS or are there any security problem I currently can't think of?
I really don't want to deal with dynamically loading a JSON parser and would be glad to simply use eval().
PS: I will obviously use the native JSON object if it is available, but want to fall back to eval() for IE/Opera.
In your scenario, the question becomes, where is PHP getting the javascript to execute from? Is that channel secure, and free from potential user manipulation? What if you don't control that channel directly?
There are a number of ways that your security may be compromised.
Man in the middle attacks could theoretically alter the contents of data being delivered to the client.
Your server traffic could be intercepted elsewhere and different content could be provided (not quite the same as a MIM attack)
Your server could be compromised and the data source could be tampered with.
and these are just the simple examples. XSS is nasty.
"an ounce of prevention is worth a pound of cure"
Besides the obvious security issues:
Native JSON is faster
You don't need to "load" a JSON parser it's just another function call to the JavaScript engine
Tip:
in asp.net using JSON is considered bad becuase parsing of DateTime differs between the server and the client so we use a special function to deserialize the date in javascript. I'm not sure if PHP has the same issue but its worth mentioning though.
check out this:http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/
so at least for firefox you can use the built in json parser
Seriously? Some of the guys here are paranoid. If you're delivering the JSON and you know it's safe, it's ok to fallback(*) to eval(); instead of a js lib for IE. After all, IE users have much more to worry about.
And the man-in-the-middle argument is bullsh*t.
(*) the words fallback and safe are in bold because some people here didn't see them.

Categories

Resources