I'm not sure if this is normal behavior or not. Everytime I access the blockchain a new private/public key pair is created and saved in .hfc-key-store. Therefore this folder becomes huge, how do you handle that? Thanks
The Node SDK supports loading existing credentials. The likely cause of this is that you are actually enrolling each time rather than using existing credentials as much of the sample code actually does this for convenience.
Related
Let say I have an application that should run on a VPS. The app utilizes a configuration file that contains very important private keys, in a sense that no one should ever have access to! I know VPS providers can easily access my files. So, how may I "hide" the sensitive data from malicious acts while still have them usable for the app?
I believe encryption will be of no help, since the decryption should be done on the same machine! Also, I know running my own private server is a no-brainier; but, that's not an option, unfortunately.
You cannot solve this problem. Whatever workaround you can find, there will be a way for someone with access to repeat the same steps. You can only solve this if you have full control over the server (both hardware and software), otherwise, it's a lost battle.
Some links:
https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
https://owaspsamm.org/model/implementation/secure-deployment/stream-b/
https://security.stackexchange.com/questions/223457/how-to-store-api-keys-when-algo-trading
You can browse security SE for some direction, and ask a more target question.
This problem is mitigated with using your own servers, using specialized hardware for key storage, trusting to your host provider or cloud, and using well-designed security protocols.
But the VPS provider doesn't know how your app will decrypt the keys in the file? Perhaps your app has a decrypt key embedded in it, or maybe it is something even simpler. Without decompiling your app they are no closer to learning the secrets. Of course if your "app" is just a few scripts then they can work it out.
For example if the first key in the file is customerID, they don't know that all the other keys are simply xor'ed against a hash of your customerID - they don't even know the hashing algorithm you used.
Ok, that might be too simplistic of you used one of the few well known hashes, but if there are only a few clients, it can be enough.
Obviously, they could be listening to the network traffic your app is sending, but then that should be end-to-end encrypted already, if you are that paranoid.
I have a node application with secrets in a configuration.
But it is running in an insecure environment.
Is there a way to store the configuration in a way that it can't be read, but can still be used by the application?
Possible Ideas (still looking for solutions on how to do them)
Node can maybe required a password every time it runs to decrypt the encrypted password store.
Compile the application. (Apparently can only obfuscate, not compile)
If there are any other solutions or how to implement any of the above possible solutions.
Is there a way to store the configuration in a way that it can't be read, but can still be used by the application?
No, there is not.
If it can be read by your program, it can be read by anyone who has access to your data/code on the server.
Any secure container on that server or on some other server that you could store it in would need credentials to get into that container which would then need a place to store those credentials. So, you have to have a secure place to store credentials in order to keep data secure.
I'm working on a web platform which will contain some rather sensitive personal information, and obviously this raises the problematic of how secure this data will be. Users can upload some files, and I was wondering what the best way was to store them securely.
I've done several searches, and one of the pages which I found quite useful was https://stormpath.com/blog/how-to-gracefully-store-user-files (I'm not using Stormpath btw, just looking for implementation ideas) which said that using Cloud services is one of the best solutions as their security is already quite tight. The caveat I've found in other discussions is that your data is stored by a third-party, and if you use Amazon-managed encryption keys, they can theoretically view your data.
Yet, overall, one thing I don't quite understand - I guess because of my total lack of expertise in the domain - is why storing files elsewhere than on your own server would be more secure. I've tried imagining a few different scenarios :
1- files stored on the webserver with no encryption
-> obvious issue if someone breaks into the server
2- files stored on the webserver, encrypted with a global key, stored outside of the "public" folder
-> if someone manages to get access to the server, they could get the files but also find the encryption key (and whatever they want actually) and access the files?
3- files stored on a 3rd party cloud provider, ewith a global key, stored outside of the "public" folder
-> well.. same issue? if someone gets access to the server, they can get the encryption key, and I guess it wouldn't be difficult for them to get the file which gives the credentials to the cloud account, and hence get the files?
Overall, it seems that whenever your web server gets compromised.. your data is basically compromised as well? The only solution would be to encrypt the files with a key only known to the user, but in practice this comes with a lot of "usability" cons : data irrecoverable if the user forgets the key, user needs to keep safe a long encryption key on top of his password, etc..
Any comments to shed some light on this topic for me?
Thanks very much
Hi security aware people,
I have recently scanned my application with a tool for static code analysis and one of the high severity findings is a hardcoded username and password for creating a connection:
dm.getConnection(databaseUrl,"server","revres");
Why does the scanner think this is a risk for the application? I can see some downsides such as not being able to change the password easily if it's compromised. Theoretically someone could reverse-engineer the binaries to learn the credentials. But I don't see the advantage of storing the credentials in a config file, where they are easy to locate and read, unless they are encrypted. And if I encrypt them, I will be solving the same problem with the encryption key...
Are there any more risks that I cannot see? Or should I use a completely different approach?
Thank you very much.
A fixed password embedded in the code will be the same for every installation, and accessible by anyone with access to the source code or binary (including the installation media).
A password read from a file can be different for each installation, and known only to those who can read the password file.
Typically, your installer will generate a unique password per site, and write that securely to the file to be read by your application. (By "securely", I mean using O_CREAT|O_EXCL to prevent symlink attacks, and with a correct selection of file location and permissions before anyone else can open it).
This is an interesting one, I can give you examples for a .Net application (as you haven't specified running environment / technologies used). Although my guess is Java? I hope this is still relevant and helps you.
My main advice would be to read this article and go from there: Protecting Connection information - MSDN
Here is a page that describes working with encrypted configuration files here
I've seen this solved both using encrypted configuration files and windows authentication. I think that running your application as a user that will be granted access to the relevant stored procedures etc (as little as possible, e.g. Principle of Least Privilege) and furthermore folder access etc is a good route.
I would recommend using both techniques because then you can give relevant local folder access to the pool for IIS and split out your user access in SQL etc. This also makes for better auditing!
This depends on your application needs though. The main reason to make this configurable via a config file or environmental user account I would say is so that when you come to publish your application to production, your developers do not need access to the production user account information and instead can just work with Local / System test / UAT credentials instead.
And of course they are not stored in plain text in your source control checkin then either, which if you host in a private distributed network like GIT could mean that this could be compromised and a hacker would gain access to the credentials.
I think it depends on how accessible / secure your source code or compiled code is. Developers usually have copies of the code on their dev boxes, which are usually not nearly as secure as production servers, and so are much more easily hacked. Generally, a test user / pw is configured on the dev box, and in production, the "real" pw is stored in much more secure config files. Yes, if someone hacked into the server they could easily get the credentials, but that is much more difficult than getting into a dev box in most cases. But like I said it depends. If there is only one dev, and they have a super secure machine they work with, and the repo for their code is also super secure, then there is no effective difference.
What I do is to ask the credentials to end user initially and then encrypt and store them in a file. This way, I don't know their connection details and passwords as a dev. The key is a hashed binary and I store it by poking ekstra bytes in between. One who wants to crack it should find out the algorithm used, key and vector lengths, their location and the start-end positions of the byte sequence keeping the values. A genius, who would also reverse engineer my code to get all this information would break into it (but it might be easier to directly crack the end user's credentials).
I am developing standalone app for cross platform using electron.
I want store private data like private key, private data for some
execution in app. Execution like encrypt / decrypt data.
Or
I want store some secured information like user password, proprietary
data on app
Are any possible way to store these kind of secure information and app user unable to get any way?
There is an NPM module made for Atom editor (the app Electron was made for) called Keytar. It uses the native OS APIs for secure storage. eg. The keychain on OS X.
https://github.com/atom/node-keytar
I don't know the specific technology that you are using, so my answer will point in general to the key storage issue.
First, two big remarks:
Even with some heavy specialized hardware (banks and other critical systems use Hardware Security Modules -HSMs- for this), there is always a risk of getting your key stolen. What you choose to do depends on how important is your key and how much are you willing to do to protect it. I will try to avoid to mention solutions involving hardware, because they are usually overkill for most people.
There are, however, good practices that you can follow: https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
Now, some advise. Whatever you do, don't store your key in plaintext (and much less hardcoded). If you are using public key cryptography, PKCS12 files (usually with extension .p12 or .pfx) are the standard way to store the data. They are usually password protected.
Here you face a problem: if you have a key, you need to use it. If you use the key, it will be in "plaintext", at least in RAM. So, you need a way to enable the access that keeps the key as isolated as possible. If the actions are triggered by a user, things are relatively nice, because you could ask for the password before using the key.
If the actions are automated, however, you need to find a way to store the password. Even security software like some PGP implementations have approaches for this that aren't nice:
Ask for the password in command line: command -password my-password. This, put in a bat, works. But the password is stored and, depending of the operating system, even available with the command history.
Store it in a file: at least you don't leave copies around, but the password is still in plaintext.
Encrypt it using system data as encryption key: the password is relatively protected, but you lose portability and an attacker with access to the computer won't be stopped by the control.
Ask for the password once one the service is on: a bit more reasonable, but not always possible (if the service is critical but just one person has the password, availability might be compromised).
Fancy things could be done with threshold decryption, but that's probably too much for that case also.
I do not provide details on each option because what you can do probably depends on what your framework allows and the way in which your system is used, but I hope it helps as a reference of the different options. In any case, do not implement any cryptographic functionality on your own. Bad crypto is worse than no crypto at all.
Avoid storing private or server-side details like a private key in an electron app. Electron app's data and file can be accessed from the app.asar file and electron do not protect the content at all. There is no such mechanism of code protection in electron. However NW.js supports source code protection, You can read it here. So according to me, it's not safe to store private accreditations like signing a certificate or private key in electron source code.
As another way, you can store these data using node-keytar in the keychain for mac, the credential manager in windows and Gnom Keyring in Linux using native api. But still, these credentials are accessible to the user and does not make sense to storing private tokens (i.e. Token for GitHub private repository having administrative rights). It depends upon the user, If he/she is sophisticated enough to understand what did you stored in Keychain, Credential Manager or Keyring, they can misuse it or can use against you. So the final answer is,
Do not store Credentials/Private key or Administrative Tokens in electron source or using node-keytar.
the perfect way of storing data in electron is this package: https://www.npmjs.com/package/electron-data-holder
this package stores data in a JSON file but it gives you the ability to encrypt the data.
read more in the documentation