I want to encrypt my API data so that the user can't see it in the network tab or as plaintext in something like the window.__nuxt__ object.
The way I'm doing this now:
encrypt data in back-end with a secret string (like a password)
send encrypted data to front-end
decrypt it on client-side (using the same password as in the back-end)
Here is the problem: The function that decrypts my data can be found by looking through the bundled JavaScript files in the Browser.
Although the function is obfuscated, it is possible the reverse engineer it. And since the password is stored within the function (it has to be, right? Since I don't have the process.env variables on the client-side) everyone can(theoretically) scrape my data.
What is the best way to prevent this?
I know that the data is visible eventually in the browser. I just don't want it the be visible in plaintext.
I'm using express in the back-end and NuxtJS in the front-end by the way.
There's no way to prevent this. All you can do is make it more difficult.
Ultimately, if the data is visible to the user in the browser, you can just get it from the DOM in memory. All the code to transform the encrypted data into the original information must be supplied if you need the user to see the data.
You can obfuscate the code, but your attacker doesn't even need to reverse engineer it to get the data, they just need to run it.
I want integrate on-line payments with my web (html + jquery). Easiest way is just send form on specific link. One of parameters is signature. Signature is hash from from fields and private key. Problem is I don't wanna expose my private key in javascript code. Is any secure way to do it?
Here is test code for form:
http://developers.payu.com/en/restapi.html#creating_new_order_form
and signature generating algoritm:
http://developers.payu.com/en/restapi.html#references_form_signature
Short answer is... No. Well, maybe but not really.
You cannot do the whole process in Javascript securely as it requires you to load the key into the users browser. That's an instant security game over.
What you can do is have a server (key store) somewhere that holds your private key and encrypts messages on demand. That would prevent end users seeing your private key, but it just moves the problem down the line - how do you know that the browser making the request is a genuine user and not someone malicious? If you just sign anything you're presented, you may as well skip the security entirely. If you're going to have a server anyway, why not use it to serve the webpages and validate form data too?
So really, you need something server-side that validates user input, checks that it's sane/untampered and then signs the message and passes it on.
You have to ask yourself why you need to do this from within a browser... The whole point of signing a message is to prove who it comes from. If it's coming from someone else's browser and you know nothing about the message, why would you sign it as authentic and coming from you?
I am attempting to 'secure' (as I know it won't be very secure) the data in a indexedDB on the client side for an OFFLINE WEB APP (i.e. anyone who is attempting to access the data will be able to see the encryption method used so I am aware that makes brute force pretty damned easy!)
I am going to encrypt it using the Username and Password as that is the only thing I could possibly keep secret.
There are loads of ways to do this, however I have one requirement that has me stumped - I need to maintain the ability to be able to search the database.
Can anybody point me in the direction of how I can encrypt data but still be able to search it.
The encryption doesn't have to be bank-level security by any means, just want to protect the database in case a tablet etc. got lost so that 99% of people wouldn't be able to view the data directly.
You can try my library, ydn-db. For encrypted, you can only search by primary key only thought.
How to hash/encrypt string value in JavaScript? I need a mechanism to do so for hiding some data in localStorage/cookie?
It is something related to security concern but I want some protection for my data.
There are lots of encryption libraries for javascript. Here's the first one that came up on Google: http://crypto.stanford.edu/sjcl/
Your user can always gain access to the key, so this won't protect data from your user. If you want to hide things from the user, you'll have to encrypt it on the server and never send the key to the client.
I have a quetion which may be simple/dumb or not :). In other words I have no idea if is fair enough or a completely foolish idea. Just some free thoughts.
What if I make my login via JavaScript with pass in it (yes I know), but pass will be hased by Secure Hash Algorithm. For instance:
I generate a pass with SHA which looks like
var = 0xc1059ed8... //etc
and paste into the code. There will be also two functions. One will compare two values (given by me with user's) and second will generate sha form user's input.
Is this could be safe theoritically or this is a horrible pattern and stupid idea? Can JS handle it?
EDIT: I didn't mean serious autentication like banking one. Just when I have my pics and want only to a few ppl to watch them and 99,9% of ppl on earth can't watch them :)
thx for responses
Sorry, no dice :) Secure authentication is not possible with client-side Javascript alone, because a positive authentication result could be faked. You will always need a server-side instance to authenticate against.
The common answer is that 'no, you can't do client side authentication' and for conventional scenarios that is correct, but I can think of at least two ways to make it work:
Use the SHA password hash to redirect to a static HTML page (0xc1059ed8...html). As long as the virtual directory doesn't allow file listing, no one will be able to guess the name of the file you want to protect. This gets clumsy really fast though.
Use an implementation of an encryption algorithm (AES, etc) in Javascript to decrypt a block of text that makes up the actual content of your page. Really only practical for one highly valuable page though.
Server side authentication is really the best, but it is incorrect to say that client side can't be done.
You cannot secure your site with Javascript alone. You will need some way to authenticate requests on the server.
Because all your javascript code is plainly visible to all consumers of your site. All a potential attacker would need to do is view souce of your website and they can bypass the password checking bit of your javascript and view the content behind it.
You need to have security implemented on the server-side, period the end. ASP.NET has a built-in way to do this called "Forms Authentication." Or you could use Session variables in a php script.
Your JS source will be visible anyway and anyone can fake it easily. You have to do a server side validation
Since the hash will reside on the user's computer (in the browser), i'd say it's a terrible idea. It will be easy to manipulate it.
You can use such a pattern to hide the password over a plaintext link and avoid https to login , but not as it stands.
The problem is that an attacker can steal the hashed password and use that to login to the server, and she does not need the real password.
This can be thwarted by a challenge response where the server sends with the page a "salt" : a big random number which is jumbled up with the password and then hashed, so the response is always different.
Unfortunately this has the effect that the server now needs to have plaintext passwords, which is a bad idea (ok, there are some tricks around this). So you might have to end up with a sending a salt, hashing your password, jumbling the hash with the salt by hashing it again and sending that to the server. The server hashes the stored hash of the password from the user db with the salt and compares both.
With security things get complicated real quickly and in complicated things opportunities lurk for the bad guys. A reason more to use well tested patterns, algorithms with a proven track record and libraries which have carefully implemented these.
And in any case it will be the server hwo has final say who can get access.
You'd be better off with no attempt at authentication at all -- at least that way you wouldn't give anybody the dangerous illusion that something involved might be secure.
Assuming you're dealing with a shared-secret situation, authentication is really pretty easy. You use a fairly simple challenge-response algorithm. Basically, the client sends a message to the server saying it wants to log in. The server responds by sending back a random number. The client encrypts that random number with the correct password, and sends it back. The server encrypts the random number itself, and compares the result to what the client sent. If they match, authentication has succeeded -- you've confirmed that the client has the right password.
The advantages of this: first, the password itself is never sent over the wire in any form, so an attacker has virtually no material to use in attempting to discover the password. Second, since the server generates a new random number for every login, an attacker cannot successfully authenticate by re-sending the packets it captured from a previous login.
Nearly any server with any sort of aspirations to security will already have something like this built in. It's purely a question of setting up your client to interact correctly with the form supported by the server(s) you care about.