I'm working in a setting where storing plain-text passwords is not acceptable, neither in files nor in databases. The Corda Enterprise guide, section 7.6.3 on RPC security, states that passwords can be encrypted using Apache Shiro, by setting passwordEncryption = SHIRO_1_CRYPT. Is this setting applied to all passwords in node.conf, or just to the RPC passwords? If it applies only to RPC passwords, how can other passwords be secured? Other types of passwords include DBMS and keystore passwords.
You correctly identified that you need the following setting in your node configuration.
passwordEncryption = SHIRO_1_CRYPT
Take a look at this page, it outlines how to specify security configuration for your node password. You simply specify it for each node and then you should be all set.
https://docs.corda.net/docs/corda-enterprise/4.4/node/operating/clientrpc.html#password-encryption
Related
I am using Redis to store the access token. I want to know if I need to encrypt the token before saving to redis. If yes then please explain why.I am using C# and Stackexchange.Redis library.
As it is stated in the security section of redis documentation
Redis is designed to be accessed by trusted clients inside trusted environments. This means that usually it is not a good idea to expose the Redis instance directly to the internet or, in general, to an environment where untrusted clients can directly access the Redis TCP port or UNIX socket.
So it is better to secure the instance instead of every individual data in it. Redis doesn't support encryption, as you mentioned you need to handle in application layer. You need to wrap the commands by encrypt/decrypt methods.
For extra security, i think you must use authentication by setting password at configuration file. It can be a long one and will be saved in the configuration file so every command will require auth as a prerequisite.
If your concern is security of the instances communicating with redis, that's another topic. auth will not help just like encryption secret. Since both secrets are in the hand of attacker, he can retrieve the original data.
I am wondering to encrypt the password for ssl setup of kafka cluster.
my current setup:
listeners=SSL://:9095, PLAINTEXT://:9094
ssl.keystore.location=keystore.jks
ssl.keystore.password=password
ssl.key.password=phoenix
ssl.truststore.location=keystore.jks
ssl.truststore.password=password
security.inter.broker.protocol=SSL
but I dont want to have a plain password , expecting the encrypted this password
I don't think kafka provides any option for storing encrypted password. This doc specifically says Since we are storing passwords in the broker config, it is important to restrict access via file system permissions.
The following worked for me:
Updating Password Configs Dynamically
Password config values that are dynamically updated are encrypted before storing in ZooKeeper. The broker config password.encoder.secret must be configured in server.properties to enable dynamic update of password configs. The secret may be different on different brokers.
Source: http://kafka.apache.org/documentation/#dynamicbrokerconfigs
We're working on a TCP server that secures its communication with its clients using TLS/SSL.
Currently we are storing our public (.cer file) and private (password protected, private key included .p12) certificates in the Windows certificate store. We are going to increase the number of TCP servers soon and depending on the traffic we'll be adding more and more in time.
To facilitate the deployment process and periodic certificate change (or in case we detect some sort of intrusion) we plan to store both (private and public) certificates in the system's common MySQL database that is accessible by the TCP servers.
Is storing the .cer and password protected .p12 files in BLOB columns a bad idea from a security point of view?
P.S: I don't think it is very relevant but the TCP server is being developed in c#.
Skipping the security concerns, your language is PKE with native support for the windows store, you are going to have to roll your own (increase complexity) with this change. It would be better as part of the server start to update the Windows Store.
From a security point of view, you now have additional points where the encrypted key are accessible. Is you password secure enough? This is not a best practice and should be managed by the systems admin doing the install and updates. Lastly, this increase of complexity also increase the attack surface.
We currently use the auth_ldap with apache for authentication and due to security compliance we have to change the auth for SVN.
The requirement is pretty simple. Users cannot save password unencrypted locally on clients. Ofcourse, the password can be set to encrypt by individual users by editing the ''servers'' but due to size of the firm, we cannot monitor this and be sure that they are doing it.
What are the available authentication mechanisms?
1) SASL + GSSAPI: I have been struggling to implement this for a while. Looks like it no longer works. See here
2) [RULED OUT] SSH Keys: There is a quite some overhead in adding and removing keys. But this is doable. Ruled out as we have some services that access over https.
3) Passwords: There must be some way to be sure that password are stored encrypted on user home dir.
PS: Not interested in deploying the repo on Widows server.
I'd appreciate if someone can add some insight into possible authentication mechanisms per my requirement.
SYSTEMS: SVN 1.6.11 on apache & RHEL6.2, Windows Server 2008 R2 Active Directory.
For those in the know, what recommendations do you have for storing passwords in Windows Azure configuration file (which is accessed via RoleManager)? It's important that:
1) Developers should be able to connect to all production databases while testing on their own local box, which means using the same configuration file,
2) Being Developers need the same configuration file (or very similar) as what is deployed, passwords should not be legible.
I understand that even if passwords in the configuration were not legible Developers can still debug/watch to grab the connection strings, and while this is not desirable it is at least acceptable. What is not acceptable is people being able to read these files and grab connection strings (or other locations that require passwords).
Best recommendations?
Thanks,
Aaron
Hum, devs are not supposed to have access to production databases in the first place. That's inherently non-secure, no matter if it's on Azure or somewhere else. Performing live debugging against a production database is a risky business, as a simple mistake is likely to trash your whole production. Instead I would suggest to duplicate the production data (eventually as an overnight process), and let the devs work against a non-prod copy.
I think it may be solved partially by a kind of credentials storage service.
I mean a kind of service that do not need a passwords, but allows access only for machines and SSPI-authenticated users which are white-listed.
This service can be a simple WebAPI hosted under SSLed server, with simple principles like so:
0) secured pieces have a kind of ACL with IP whitelist, or machine name-based, or certificate-based whitelist per named resource, or mixed.
1) all changes to stored data are made only via RDP access or SSH to the server hosting the service.
2) the secured pieces of information are accessed only via SSL and this API is read-only.
3) client must pre-confirm own permissons and obtain a temporary token with a call to api like
https://s.product.com/
3) client must provide a certificate and machine identity must match with the logical whitelist data for resource on each call.
4) requesting of data looks like so:
Url: https://s.product.com/resource-name
Header: X-Ticket: value obtained at step 3, until it expire,
Certificate: same certificate as it used for step 3.
So, instead of username and password, it is possible it store alias for such secured resource in connection string, and in code this alias is replaced by real username-password, obtained from step 4, in a Sql connection factory. Alias can be specified as username in special format like obscured#s.product.com/product1/dev/resource-name
Dev and prod instances can have different credentials aliases, like product1.dev/resource1 and product1/staging/resource1 and so on.
So, only by debugging prod server, sniffing its traffic, or by embedding a logging - emailing code at compilation time it is possible to know production credentials for actual secured resource.