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.
Related
The widely acknowledged configuration of SSL for Apache is to point to the location of Certificate and private key.
Can we configure SSL without storing the private key in a file, rather by keeping it in memory?
You could use Keywhiz for this:
Keysync is a Keywhiz client that retrieves secrets from a Keywhiz
Server using mTLS with a client certificate and stores them in tmpfs.
Presenting secrets as files makes Keywhiz compatible with nearly all
software. Outside of Keywhiz administration, consumers of secrets only
have to know how to read a file.
Keysync stores all secrets in memory only (via tmpfs) and never
persists them to disk. If the server loses power, all secrets will be
safely removed from that server.
Keysync's design mitigates a Keywhiz Server outage, since all
necessary secrets are stored locally, and can be accessed even if
Keysync process is restarted. The full sync of secrets is only
necessary in the event of a server reboot.
I am using PKCS11Interop to perform Key Management operations inside an HSM. The HSM I am using is a network HSM, Thales N-Shield. Here are the details of my setup:
1- HSM
1- RFS Server
3- Clients
My software application is distributed and is hosted over the 3 clients. The key will be generated in one of the clients and could be used by the application components present in other clients.
However, I have noticed that a key generated in one client machine is not accessible to other client machines until unless both clients do an rfs-sync.
Question: Is there a way to synchronize the client keys with the RFS using some PKCS11Interop API? If No, then in what way I can synchronize the keys between RFS and the Client machine.
I know that an exe can be execute using C# code but doesn't look like a clean apporach.
What you are trying to do is not part of the PKCS#11 standard. So I doubt that PKCS11Interop will be able to achieve this (from looking at its documentation here).
When you generate an object on the token (Thales n-Shield) using PKCS#11 (PKCS11Interop), the Thale's security manager that's installed on the client is actually doing the generation on the HSM. If I remember correctly, the Thales stores these objects on the client machine as flat files encrypted by the security manager's master key. So technically it is not stored on the HSM. This is the reason you have to do a sync with the RFS, and then update your other clients to see the new keys/objects.
You will have to check with the Thales people to see if they can provide a way to automate this. Or you have to implement your own synching mechanism. Since the rfs-sync is a command line tool Thales provides, you will to see if you can execute the commands through C#. Or check with them if they have a C# library that does this for you.
Our current infrastructure uses ssh keys for passwordless login to our Linux servers.
As our infrastructure grows, managing these authorised keys is getting harder.
As we also have an Active Directory (AD) server, I would like to authenticate the users over ssh using this mechanism, but maintain the passwordless nature of ssh keys.
Is it possible to authenticate the users over ssh without password, using some AD mechanism?
This is usually done via SSH key certificates in order to keep the password-less nature and at the same time have a Central Authority that can be trusted to generate new certificates for each account.
LDAP/Active directory use on login is not advised - apart from having to use passwords, it also becomes a single point of failure for access to any system it manages.
See RedHat documentation on how to do this and also Facebook's good write up on their use of certificate authentication with SSH.
Option 1
This is a good article explaining how to do this.
Storing SSH keys in Active Directory for easy deployment
Basically, it will allow people to post their public keys to your Active Directory and then you can set up a cron script on your servers to fetch a copy of the public keys every 5 minutes or so.
Option 2
You could also use a file server that has all your keys and get each server to fetch from there using a cron script. Obviously, you need a way to verify each key's authenticity especially if you are using FTP or some other insecure protocol. This could be achieved using GPG. You could have a company master GPG key that signs all the employee keys.
Personally, I like option 2 the best because I think it is more secure, but either method should work. Hope this helps!
My approach would be to reduce the problem to an already solved one by
Use active directory to authenticate without password and establish an HTTPS connection using Kerberos. The Dzone Tutorial Configuring Tomcat 7 Single Sign-on with SPNEGO might be a good starting point for that approach.
Wrap SSH into the https-protocol like, see section Wrapping SSH in HTTP(S) at https://unix.stackexchange.com/questions/190490/how-to-use-ssh-over-http-or-https
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
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.