Would be a good or bad idea to use localStorage for sensitive data (assuming the current HTML5 implementations)?
What methods can I use to secure the data so that it cannot be read by a person that has access at the client computer?
Bad idea.
Someone with access to the machine will always be able to read the localStorage, there is nothing much you can do to prevent it. Just type 'localStorage' in firebug console, and you get all the key/value pairs nicely listed.
If you have an XSS vulnerability in your application, anything stored in localStorage is available to an attacker.
You can try and encrypting it, but there is a catch. Encrypting it on the client is possible, but would mean the user has to provide a password and you have to depend on not-so-well-tested javascript implementations of cryptography.
Encrypting on the server side is of course possible, but then the client code cannot read or update it, and so you have reduced localStorage to a glorified cookie.
If it needs to be secure, its best to not send it to the client. What is not in your control can never be secure.
Public Key Cryptography can be applied to prevent any kind of intrusion. Also, data integrity checks (such as CRC or hashes) may be used to make sure data is validated by the server.
Related
I've edited this question. I hope this version is a bit more clear.
I am seeking to have a programmer build a process for me. I need to ensure what is recommended is a best practice for the below process.
Here are the steps I need to have built:
Have a https: webform on my server that submits client inputted data into a database on my server. The data is personal identifiable information and needs to be securely transmitted in the next step.
Once the data is loaded in my database, I need to transfer the data in an encrypted/Json format to a third-party server. The third-party will unencrypt the data, score it and send it back to my server encrypted.
While the data is being sent and scored by the third-party, the client will see a browser screen indicating processing...
Once the data is scored and sent back to my server, it will be unencrypted and it will update the client's browser with options based on the score given by the third-party.
Based on what I understand, I think an API on both my server and the third-party server might be best.
What is the best practice approach for the above process?
Below are some questions I have which would be very helpful for me to understand in your response.
Is the API approach the best?
What process is used by the third-party to unencrypt data I send and vice versa? How do I prevent others from unencrypting the data if it is intercepted?
3)While the data is being scored by the third-party, the client browser will show processing. From a web development standpoint how does this work? Also, from a web development standpoint, how exactly is the processing screen triggered to update with results on the client's browser screen when the data is sent back from the third-party?
The file that you will be transmitting, as you mentioned is encrypted so it will totally depend on the encryption algorithm you are using, generally encrypted data are stored as BASE64 or HEX so after encryption the data will be passed in the above-mentioned format.
To answer you second question on "how will the receiving website receive the file?", there are several ways you can do this:
You can share the backend database your website is using then it will just be a simple query away (by shared I mean both the websites use the same database).
Another way of achieving this is to use an API which can store your data and can be globally used in any application it is called at
Or you can set up a simple php server locally at your machine and send data between websites using the HTTP: GET or HTTP: POST requests.
also avoid using un-necessary tags like web-development-server or data-transfer or transmission etc. these tags are useless and unrelated to your question. You should only tag those which are related to your question, a simple tag for web-development would be enough.
also edit out your question to make us properly understand, what problems you are facing? what have you tried? what do you expect from us in the answer?
please clarify your question more.
Your concept of files being sent around is kind of wrong, because in most cases none of this is ever been written to disk, and so there is no JSON file with a file-name - and these are not directly being encrypted, but only pushed through an encrypted channel. Most commonly both sides either use HTTPS or WSS as the protocol, which encrypts / decrypts the data being exchanged transparently (all by itself). And depending on the protocol which is being used, this requires either a combination of client & server, server & server - or a P2P network - to be installed.
Further reading: Internetworking Basics - Computer and Information Science.
I was intending to release a website to the public that stored sensitive information on the client side using Local Storage such as API keys. Variables stored in Local Storage are used in my PHP scripts.
I was thinking, since it had an SSL certificate, this would suffice for storing sensitive information such as an API key and secret.
My website will not have ads. The website also has a MySQL database.
I am going to configure a general user for reading data in since a user does not need write privileges (it is a read-only site). The problem is if they went on a malicious website later on, they could extract these Local Storage keys (maybe with a script) and potentially hack my consumer.
The names are very generic on my website when creating and using the keys so it would be hard to identify the origin of the keys or what their purpose is.
Is this wrong to do this to my consumer?
Yes, it is wrong. It means a huge security leak. Imagine the case when any malicious Javascript is executed in the browser for any reason. It will be able to read the content of localStorage and send it to the hacker.
This could be caused by a website problem, such as possibility of XSS injection, but a browser extension with malicious content can achieve the same. While XSS injection can be protected against, if the developers of the site are careful, what browser extensions the users will install is beyond your control. Avoid this approach. Store sensitive data safely on the server.
I am building a chrome extension that needs to persist user sensible data.
I know that you can use HTML5 but it is vulnerable to XSS, and possibly other form of attacks. I recently found out about chrome.storage but the docs say:
Confidential user information should not be stored! The storage area
isn't encrypted.
Now my question is:
Is there a secure way to store sensitive user data (i.e. a private key) in the browser?
The default content security policy pretty much protects you from XSS assuming you don't do anything really stupid. You could use some sort of a library to to encrypt local data and make users enter a passphrase to decrypt the data. The attack vectors at this point are more around malware on the computer and other people with physical access. Chrome extensions themselves are well protected from other sites.
Ultimately though, anything installed on the computer or having access to the computer has the potential to access the private info regardless of what you do. My recommendation would be make sure users are aware of how sensitive the data being stored is and that they need to maintain proper security precautions around getting access to the computer.
I've setup a web server and can exchange data between it and my iPhone by using JSON.
Is JSON already encrypted? I'm trying to make an app that people can use. I'm not sure how to securely verify a user. Right now I'm having them send some information that uniquely identifies them along with their GET requests.
But couldn't someone easily pick this up, and then replay the GET request to the server to access the same information?
What's the right way to do this?
JSON is not automagically encrypted, no.
Secure your server with SSH. This should prevent most MITM type attacks. If you are extremely worried about replay attacks from the client side (browser), you will probably need oAuth + a secure nonce.
No security measure will protect you 100%, you have to compromise security vs performance.
If you are worried about MITM attacks, most likely someone sniffing requests on your network and then replaying them, you could set up SSL and send the JSON request via that, which would prevent the attack.
The only other thing is that via GET your security variables will be exposed in the URL.
Whether it is ideal form is what kind of information you are transferring and what other authentication you are using.
http://joekuan.wordpress.com/2010/05/08/quick-steps-on-setting-up-apache-ssl-php-json-on-freebsd-8-0/
I receive data, and use aes or blowfish to encrypt it before saving it to the database, so the encryption is done at the application level. If someone steals the database, the data will be relatively safe unless they stole the application also (where the key is stored/accessed).
I'm now looking into database encryption with libraries like ezNcrypt for MySQL, Encryption-GENERAL, or SQLCipher.
But I don't quite understand how database encryption works. If the application only passes raw unaltered data to the database, and the database decrypts the data itself somehow, wouldn't that make database-level encryption less secure if the database was stolen since 100% of the encryption component was stolen?
In my current situation, if a database is stolen, the attacker would have to steel the second component (the key which is at the application level) to decrypt the database. But with database encryption, the database itself has full responsibility of the encryption, so by stealing the database, wouldn't the attacker have everything needed to decrypt the database?
Maybe I'm not clear on how database-level decryption works.
The encryption algorithm is applied at different points in your application stack, but at the end of the day the process is exactly the same regardless if you use an application or db-layer solution. The key has to be stored somewhere and if an attacker gets both the encrypted data and the key, then they have access to the data.
So, the real question boils down to how you store your key:
Plaintext - if it's in plaintext somewhere in the filesystem then that's your weak point. Maybe it's in the application code, maybe in a config file somewhere. In any case, someone who gains administrator access to the server (or simply steals the hard drive) has what they need, and obscurity is your only protection.
Manually-entered - If you have a human user enter the key when the application/database/pc is started, then you mostly* alleviate the issue of a plaintext key. In exchange, you require a user to remember the key and you give up the ability to have a completely automated restart (bad news for a server that needs to stay up).
* I say mostly because technically the key is still available in plaintext somewhere in RAM. But that's a lot harder to get at than something stored on disk (memory swapping notwithstanding).
Regarding MySQL specifically, you might find this thread helpful.
What method do you use to authenticate your users? If the authentication method is the same in each case then encrypting in the application is not likely to be any more or less secure than in the database. The most likely vector of attack is still the same. It seems much less likely that an intruder would have an opportunity actually to steal the database rather than just gain access to it - unless you are doing something very silly.