I'm storing options data in a chrome extension using chrome.storage.local.set
How secure is that data?
Can it be read easily by anyone who has access to the file it is stored in?
It is not secure, and per the official chrome.storage docs is stored unencrypted in the user's profile folder under their Chrome data directory. You will need to use some additional encryption if you are storing more sensitive data using these APIs.
They are stored in a LevelDB database in the following location:
C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\<Extension id>
It's saved in the following path (For other OS, the path is similar), can be easily accessed.
C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\<Extension id>
Basically, since the data is saved in local machine, you can't trust it as secure, since there're tons of ways to get the data. For example, other extension/scripts may overrite chrome.storage.local.set and they may get the data first, like what Storage Area Explorer does.
Related
I have a web app that uses known username and password combinations to login to external servers. There are multiple username/password combinations used for different services. Right now, they are essentially "hard-coded" into the website code, but, I would like to move this information off the code base for better security.
My initial thought is to store this data in the database which is used to support the website. I want to store it in a way that it is not easily "hackable" (i.e. I'm not going to store it as plain text or as a MD5 hash). Should I follow the same format that I use to store the website user's passwords, where I use a random number generator to create SALT for each password and then store the password as hashed combination of the password and SALT, or would this be overkill?
Generally, storing passwords in the application code is always a bad idea. Moving it outside the code has many advantages including security.
Now storing it either in DB or Configuration Files is a choice you have to take depending on your application.
For full security you should never store passwords in retrievable form. But to login to a external server as in your case, you need to get the actual plain text password, so one way hash will not work for you.
In our product we deal with such situation by using 2 Way SSL Certificates. It is very secure and there is no need to store the passwords.
But if you really need to store the passwords, then I will suggest to use configuration file and let your application read it. You can encrypt the passwords stored in the configuration files (Encrypting the passwords stored in the configuration file will again bring you back to the same question of how to protect the key). The access to the configuration file should be restricted (in Unix, 600 File Permission).
Alternatively, if your web application is Java, then you can consider using JNDI.
After more research, I've decided at this point to follow the ideas here:
Encrypt a Column of Data - SQL Server | Microsoft Docs
...and encrypt/decrypt on the DB inside a Stored Procedure.
I am creating a website for an organisation. All of the user details are retrieved from the Microsoft Graph API. The only thing I need help with is that after retrieving the binary for the current user's profile picture, I don't know where I should store the picture. I have figured out how to convert the binary to base64 and display it on the webpage, I just don't know where to place the image. I would prefer not storing it in the database or storing it permanently on the server. I have experimented with storing it in the session token, but that didn't work as the session token was not big enough to store all that data. My website is using Python 3.7.0 and Flask with Jinja2 as the templating system. On the front end, I am using JavaScript and JQuery. Any suggestions would be greatly appreciated! Thanks in advance.
Why would you want to store user's personal info in a session, given it's deleted after the session ends?
If it's to be efficient with your API calls, a better solution is to use caching and memoizing.
https://pythonhosted.org/Flask-Caching/
If not, I think your best bet is to store it as a BLOB on your filesystem.
[EDIT]:
If you want it to last as long as your session object but can't use for some reason can't use the session object, you can look into setting it as a _request_ctx_stack local as such:
setattr(_request_ctx_stack.top, 'user_image', user_image)
And to fetch it back use:
user_image = LocalProxy(lambda: getattr(_request_ctx_stack.top, 'user_image'))
now you can import it from wherever the user_image variable is defined
I create a web server with Node.js. The database is MongoDB. I'm using a json file to save the server configuration. The node module 'nconf' is used to read the json file.
Currently, all the data, including some confidential data, saved in the json file is plain text. I don't think it is security enough. What should I do to make sure the confidential data is security?
You could take a look into the crypto library of node.
Here is a link to the documentation: Crypto Node.js
You could use this to encrypt some of the data that is contained within the file. But you should also probably consider removing the sensitive information and find another means to store it else where, perhaps within a database, like your MongoDB.
I'm going to create a Java Application for collecting some enterprise information.
My problem is the DBMS security.
EDIT: My Application is not connected to Network and the whole DB and App. are located on the system that app. is accessed from there; Users has ACL so I don't want a user be able to read data that hasn't access to them by using database files on the disk.
I need a DBMS that encrypt data on disk to protect data against someone with a Text/HEX editor or other SQL Browsing Tools (Like SQLite that has no security mechanism or ...)!
Which DBMS can I use to be sure that data are accessible only through my application (and of course DBMS itself) and not directly from the disk?
Does MySQL or PostgreSQL have such a direct disk access protection mechanism?
Thanks
If the individual has access to the disk itself, there's a good chance that he will have access to the code and other data of your application. And the encryption key (used to encrypt the DB file) will be available as well. This problem doesn't have a universal solution (see one approach below) if the computer device gets into wrongdoer's hands.
Putting the above aside you have several options:
SQLite has whole-DB encryption plugin.
You can mount the disk using TrueCrypt or one of its alternatives
We have several products (namely SolFS and CallbackFilter) which let you encrypt the DB file on the fly either using the virtual disk (SolFS) or by encrypting/decrypting files on the fly by filtering file I/O requests (CallbackFilter).
If you are able to have the user provide a password / key in some way, then you can use a session key to encrypt the database data, and then encrypt this session key using each user's password. Then, when the user wants to access the data, you ask him for a password, decrypt the session key and use the key to access the DB. In this way the key used to encrypt the data is not stored in "cleartext" and getting physical access to the disk doesn't reveal the data.
We're providing a web form whereby users fill in their personal information; some of it is sensitive information (SSN, Birthday, etc). Upon user submission, the data is prefilled into a PDF which is then made available via a link.
We are creating the PDF in a folder that has write access on the website.
How can we safely create and add PDFs in this folder, with whatever naming scheme (use a GUID?), such that another user cannot guess/spoof the PDF file location, type this in the URL and access another person's PDF?
Maybe the PDF folder has rights only specific to the user, but that may be a different question on how that is accomplished. (The number of users is unknown, as this will be open to public).
Any thoughts on this? In a nut shell, we need to allow the user to view a PDF of the data they just entered while preventing more-savvy users to figure out the location of PDF files, allowing access to other files.
Thanks!
trying to obfuscate the path to a file isn't really making it secure. I would find a way to email or another way to fetch it for the user instead of allowing access to an open directory.
Make the web app fetch the file for the user instead of relying on web server open folder permissions.
just keep in mind obfuscation isn't really security.
If it's really just for the moment, create a completely random file (20384058532045850.pdf) in a temporary directory, serve that to the user immediately and remove it after a certain period of time.
Whether your web app has write rights on that directory or not (I assume you are talking about chmod user rights) is not important, it can't be breached trough the web server and I don't see a problem in revealing the directory path per se - you have to reveal something in giving the user a URL to download. If your PDF names are random enough, there is practically no risk of somebody being able to guess the name of another PDF file in the same directory.
As the PDF contains sensitive data: Don't forget to turn off caching to prevent a local copy of the PDF being saved on the client's browser cache.
I don't know for sure whether turning off caching through the appropriate headers is enough to prevent local caching in all browsers. You might have to look into that.
For the purpose of pdf's, would it not be better (I know I will get flamed for this) to store the actual pdf into the database as a BLOB, which would be on the back-end of the website in question?
There will be no reference to the URL anywhere nor will there be a specific path highlighted in any links on that form.
Hope this helps,
Best regards,
Tom.
The simplest way is to proxy the file through your application (fpassthru() in php for example), this allows you to use what ever access control/identification system you already use for the dynamic content.
If you don't have any means of identifying your users and restricting access, and assuming your platform has a secure session mechanism, you can protect the file by storing the filename in the user's session and then returning that file (and only that file) to the user when requested. This should mean that an attacker would have to spoof a session to access the file so this should be as secure as your session mechanism is.