For example, I have a npm package which is a cli-tool. Users should set their yahoo email and password first before using the functionalities.
My question is where should I store the personal data? Is there a convention?
Most cli's use a hidden configuration file commonly stored in the home directory of the user. For example .cli-config, it is also good to store the configuration data as JSON or YAML.
Finally be carful to save sensitive data in the config file as it still is just a file and can be accessed by anyone with correct permissions.
Related
I would like to save user file in my project, such as user's profile image(jpg) or user's grade information(xml).
Now,I know
how to implement upload process in express
how to use static file path in express (at "public" dir) (for "CSS", "JS", "page image")
But, If I upload user's file in public directory, client can access file in public directory just with url like "my_website/public/.../....xml". I think it is not good for security because everyone can access others' profile image, grade information, and so on.
So, my question is
Is it okay to save user's sensitive information in public(static) directory?
If not, is there any way to save file safely except database?
In real websites, where they save user's sensitive information file? Is it in same directory with server files like main.js? or completely another server?
Is it okay to save user's sensitive information in public(static) directory?
No, it is not OK. That allows anyone access to private information.
If not, is there any way to save file safely except database?
Yes, there are other ways. For example, you could store a user's information in a directory just for that user and only allow users access to their data in their own directory. This obviously required authentication with some sort of username and a credential/password. You won't be using express.static() to access private information. Instead, you will create a route for each type of resource, verify who the logged in user is and provide access to only the resources that belong to that logged in user.
In real websites, where they save user's sensitive information file? Is it in same directory with server files like main.js? or completely another server?
There are lots of ways to implement user-specific storage, but it is highly unlikely that it is stored in the same directory as other server resources (like code files). User-specific data would be stored somewhere else.
I want to build a command-line application using Go or Node.js. I want to make it multiuser, so a login feature is needed. I can implement the login feature but I don't understand where should I store the user data which can be fetched any moment at runtime.
The user data is needed to check if a user is logged in or not if he is logged in which user it is.
Need help with a method to store user data to check logged in status
Edit:
I had thought of this- If the config file is present that the user is logged in else not. Then I realized that if one tampers the file, the whole point of login feature will get invalid. I am guessing there must be a better way to do it, which I am trying to know by asking here
Many cli utilities opt to store their configuration as a plain text file on the user's home directory.
You can use any of the available configuration formats such as JSON, TOML, etc.
Although it's good to mention that this is not a secure way of storing data and if users should not be able to see others information in any way this is not the preferred way.
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.
We're planning a secure Node.JS server, which uses several third-party web services. Each requires credentials that will need to be configured by the operations team.
Clearly they could simply put them in plain text in a configuration file.
Microsoft .NET seems to offer a better option with DPAPI (Data Protection API) - see Credential storage best practices. Is there a way to make this available through IISNode? Or is there any other option to secure such credentials within Node-JS configuration?
There's an extensive discussion of several options here, including the two suggested by xShirase:
http://pmuellr.blogspot.co.uk/2014/09/keeping-secrets-secret.html
User-defined services solves the problem, but only for Cloud Foundry.
This blog http://encosia.com/using-nconf-and-azure-to-avoid-leaking-secrets-on-github/ points out that you can often set environment variables separately on servers, and suggests using nconf to read them and config files separately.
I still wonder if there are specials for IIS?
There is 2 ways to do it securely :
First one is to use command line parameters when you launch your app.
These parameters are then found in process.argv
So, node myapp.js username password would give you :
process.argv[0]=node
process.argv[1]=/.../myapp.js (absolute path)
process.argv[2]=username
process.argv[3]=password
Second is to set the credentials as ENV variables. It is generally considered as the best practice as only you have access to these variables.
You would have to set the variables using the export command, than you'd access it in process.env
I currently had to do the exact same thing for my External API credentials. this is what i did
install node-config module
create a folder and file called config/config.js
here require(config) module
In local box it reads the configuation from local.json file
i have dummy values in local.json for api key and shared secret
on my QA environment i export two variables NODE_ENV="QA" and NODE_CONFIG_DIR="path to my configuation folder on qa server"
node-config module reads configuation from "path to your config folder / QA.json"
now i have real api key and credential in QA.json
here you can use an encryption to encrypt these values and put it back in QA.json
in your app get these config values and decrypt use it in your rest call
hope this helps.
so your config can live in the same container as node code.
refer to this for encryption and decryption
http://lollyrock.com/articles/nodejs-encryption/
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.