We are building a Rails application and one of our clients had asked if we are using industry-standard 256-bit encryption to ensure the confidentiality of personal information.
Are there are any gems which can be used to enforce this?
First enforce the use of ssl in rails. A good summary how to do this can be found in http://www.simonecarletti.com/blog/2011/05/configuring-rails-3-https-ssl/
Second you have to configure your webserver, so that it forces clients to use aes256 for secured connections. If you are using apache, you might start reading here http://httpd.apache.org/docs/2.4/mod/mod_ssl.html
That should be about it.
Related
I have developed security sensitive App. I had to use TEA based algorithm to encrypt/decrypt data to communicate with server and follow Server protocols. I have used AsyncSocket for trasport level communication which uses CFNetwork APIs. I have noticed that TEA algorithm is not very secure and can be hacked easily. Moreover, AsyncSocket library isn't using Apple's Security Framework anywhere. I am planning to rewrite transport layer and redefining client-server security protocols. I have been researching on what kind of security algorithm should I use for data protection which has no or minimum performance impact and difficult to break. Moreover, I am going through Security frameworks but couldn't find any example that uses this framework to implement transport layer. Could someone please assist me on this? What are the things I should follow to code secure transport layer? what are the security measures that I could check against my App?
As #CodesInChaos notes, you should use TLS for this. You absolutely should not design or implement a new transport protocol.
The fact that CFNetwork supports TLS does not mean that you are using it. You need to actively use it. Your server needs a certificate that your client trusts, and it needs to negotiate a TLS session. In general, if you just use HTTPS and the standard NSURLConnection routines , then you're going to get most of what you need for free. But if you start building it by hand in CFNetwork, you need to make sure that you're configuring it correctly. My recommendation is to use HTTPS whenever possible. It's simple and makes a wide variety of problems go away.
That said, just because the transport is secured does not mean that your app is "secured enough." In particular, your server still needs to be able to deal with malicious clients talking over a secured transport. You need to properly authenticate the user and you need to handle malicious data gracefully. When the data reaches your server, you need to store is securely. You may need to encrypt data on the client. There are many aspects to securing a system beyond the transport.
I'm making a website that I'm planning on making readily deployable by users; they'll be able to take my source code and deploy it to their own server and run it as their own.
I was thinking of trying to incorporate SSL and OpenID and other features into the website. Would giving the users access to these files (such as my OpenID/Twitter/Facebook client key and secret, or the SSL certificate stuff, or whatever else..) be a potential security hazard or anything? Would they be able to do anything dangerous with this information?
SSL is not the app's concern
All client key and secret are your own responsibility... I wouldn't distribute them openly.
Normally what one does is to read this information from the environment
facebook_client_key = ENV["FACEBOOK_CLIENT_KEY"]
so the deployer has only to configure the environment, not the application.
I would steer clear of adding things like your clients keys and secrets to any files you distribute to your users. They're called secrets for a reason! I don't known the ins and outs of Facebook or Twitter's APIs but certainly with products such as Akismet, the anti-spam addon for Wordpress, the key is used to identify your particular Wordpress instance.
If you are using a Wordpress site for commerical purposes, you're supposed to pay for Akismet. The problem is that whilst you might not be using it yourself for commerical purposes, depending on what you're making and distributing that's not to say that other people won't use it for commerical purposes, and end up ruining it not just for you, but for everyone else using your software.
You should make the keys and secrets part of your application's configuration and, perhaps, provide instructions on how your users can obtain their own.
I'd like to authenticate the caller of my SOAP webservice (deployed in Ruby 1.8.7/Rails 2.3.5using datanoise gem in Red Hat enterprise linux 5) using some encrypted tag in the XML requests. Normally the client is a windows program (maybe C#/.Net windows programs - not Java/Ruby) which should generate a varying encrypted key in each call to the webservice based on a key/salt - while my server side would always be able to decode it with the private key. Knowledge of the encrypted token on the wire should not allow a third-party program to simply replicate the fully encrypted token and access the webservice. I am looking into OpenSSL but am a newbie to cryptography. The string being encrypted for identification could be (among other items) the MAC ID of the trusted client, which when decrypted would match the stored value on the server side of the trusted hosts.
I've found lots of possibilities on the Ruby side, but need to ideally ensure that the solution does not impose (or minimizes) any library or installation requirement on the windows client side. What i'm most struggling with is a way to generate a new key each time the call is made, so that anyone sniffing the traffic cannot simply infer the mode to create the encrypted tag by getting access to the key.
As you are authenticating the caller here and not necessarily just the contents of what they send, there's no need to put the authentication mechanism into the SOAP request. Others have tried to do what you are after with WS-Security, so if at all, I'd go with that.
There have been problems with the security of the scheme, though, but probably the biggest deal breaker is that there's no support for it available in Ruby (that I know of at least, please correct me if I'm wrong!).
Probably the easiest way to achieve client authentication on both ends would be using mutually authenticated TLS (the former SSL). This will ensure authentication on the transport level, which should suffice in your case. Actual authentication will then happen by first checking the validity of the certificate that is sent by the client (Ruby OpenSSL takes care of that for you), and once that is established, you check it against a white list of known certificates that you maintain on your server.
Please don't invent your own scheme, cryptographic protocols are among the hardest things to get right (that's why there are problems with WS-Security), TLS is probably as good as it gets right now and it has broad support in any language.
I'd like to be able to secure files uploaded by clients.
I haven't really found plug-and-play tools for Rails apps.
I'd like to use Amazon S3, but their server side encryption is a joke even though it provides an incremental improvement in security.
Let me define security standards that I find worthwhile if one bothers with encryption:
make user's password and files invisible (or hardly visible) to the staff
This can be accomplished by storing secure hashes of the password and encryption keys.
One can take the hash in the browser using javascript which is a little bit more secure than doing it inside Rails.
Questions:
Is it worth the hassle of doing hashing and key generation in Javascript? Looks like there are libraries for hashing.
If you need to store client's password and/or master key (for file encryption), what would be the approach conceptually?
Are there ruby libraries to do file encryption or do I have to find a way to use Amazon S3 Java SDK?
I need to store payment gateway processor username/password credentials on a production web server, but would prefer not to do so in clear-text. What is the best way to store these credentials? Are their best practices for encrypting and decrypting this information?
It's a classic chicken-egg problem. Encryption does not help you at all if you can't protect the keys. And you obviously can't.
What I would suggest is to try to make the other services / users use hashes towards your authentication code, and save those hashes instead. That way at worst you will lose the hashes, but it might prove hard (depending on the rest of the setup) to actually use them maliciously. You might also want to salt the hashes properly.
An other possibility would be using an external authentication store if you can't enforce using hashes. It does not really solve the problem, but you can control the attack vectors and make it safer by allowing only very specific contact with the actual source with the important data.
Store outside of any directory that is web accessible.
Make sure only the app processes have read access.
Harden server.