I am using firebird server 2.50. As far as I know there is no way to encrypt a database in Firebird. So how to secure the user data?
Manually encrypting all data before saving would cause trouble since i will not be able to use something like "starting with".
I use CentOs for Database servers. These servers are communicating with an Application Server which runs on Windows Server 2008.
Encryption is one kind of several protection measures which can be done against potential adversaries. And there are other methods too. You need common security analysis before you go with decision whether to encrypt or not, and if not than what. You have to look who are adversaries, where they could hit, etc-etc-etc. Blind use of encryption may be waste of resource/time/money/etc. Do security analysis first.
DB encryption is possible in version 3:
With Firebird 3 comes the ability to encrypt data stored in database. Not all of the database file is encrypted:
just data, index and blob pages.
To make it possible to encrypt a database you need to obtain or write a database crypt plug-in.
Refer to Firebird-3.0.0_Alpha1-ReleaseNotes for details
Related
I am learning how to use socket.io and nodejs. In this answer they explain how to store users who are online in an array in nodejs. This is done without storing them in the database. How reliable is this?
Is data stored in the server reliable does the data always stay the way it is intended?
Is it advisable to even store data in the server? I am thinking of a scenario where there are millions of users.
Is it that there is always one instance of the server running even when the app is served from different locations? If not, will storing data in the server bring up inconsistencies between the different server instances?
Congrats on your learning so far! I hope you're having fun with it.
Is data stored in the server reliable does the data always stay the way it is intended?
No, storing data on the server is generally not reliable enough, unless you manage your server in its entirety. With managed services, storing data on the server should never be done because it could easily be wiped by the party managing your server.
Is it advisable to even store data in the server? I am thinking of a scenario where there are millions of users.
It is not advisable at all, you need a DB of some sort.
Is it that there is always one instance of the server running even when the app is served from different locations? If not, will storing data in the server bring up inconsistencies between the different server instances?
The way this works typically is that the server is always running, and has some basics information regarding its configuration stored locally - when scaling, hosted services are able to increase the processing capacity automatically, and handle load balancing in the background. Whenever the server is retrieving data for you, it requests it from the database, and then it's loaded into RAM (memory). In the example of the user, you would store the user data in a table or document (relational databases vs document oriented database) and then load them into memory to manipulate the data using 'functions'.
Additionally, to learn more about your 'data inconsistency' concern, look up concurrency as it pertains to databases, and data race conditions.
Hope that helps!
I am making a website with nodejs and mongodb which records the username of the currently online users. I wonder whether it would be better practice to store this in an array created during the website's runtime or should I store it in a database?
I agree with explorer. Generally, when an app is in production, you store information in some sort of database. This insures that your application uses the least possible RAM, assuming that you write decent code. Also, if your application crashes for some unforeseen reason, you can recover quickly and your data isn't lost.
Could anyone point me to documentation of encryption options available for couchbase? With SQL Server we have the option to encrypt data at table or db level. Is it possible to encrypt couchbase data in a similar way?
I believe that Gazzang is what you want to look at in regards to data encryption for Couchbase:
Gazzang for Couchbase offers a powerful, policy-driven solution that enables you to encrypt your data stored in Couchbase Server. With Gazzang, data files in Couchbase Server are encrypted on disk. This ensures that your data is not compromised if your database is stolen, copied, lost, or otherwise improperly accessed.
Source and more information on Gazzang: http://www.couchbase.com/couchbase-server/connectors/gazzang
You could also use file system encryption - windows provides the option.
We want to use Milton WebDav to transfer files in our web application which eventually is going to be deployed on cloud environment (most likely azure) as IaaS.
Now we are aware that WebDAV standard is stateless and hence it should not create any problems with cloud load balancer, but what we are not sure about Milton and have few questions:
1.) Is Milton implemented WebDAV as it is, do all the communication remains stateless? I assume that it passes Authentication token with every request but I am not sure where is the token stored at server? Does it store it in the database or some sort of cache etc.?
2.) Do locking mechanism works fine if a load balance is used and there are 5-6 servers to handle the load? Again where does Milton server store Lock Token?
Sorry for the late comment, the two most important aspects of webdav which affect load balancing are digest authentication tokens (Nonce values) and lock tokens.
As the Resource implementor you get to control both of those. Lock tokens are typically stored in a database (you must implement the methods on LockableResource which will do the persistence) so will be shared across servers, although its not uncommon to use memory based lock tokens, in which case you need to find some way to share that information across servers.
Digest nonces are only a consideration if you've implemented DigestResource. The default NonceProvider uses a simple HashMap so this will not be shared across servers. But the interface is trivial so you can easily implement a database store. If your load-balancing solution uses sticky sessions then that won't be an issue because clients will go to the server which has their nonce.
Note that Tomcat session replication won't help with the above issues, because webdav clients typically dont support cookies, so there is no Servlet session.
I have never used Milton WebDAV before but from the looks of it, it is used to modify and edit files on a server.
However Azure's local storage is not shared. Each instance is a completely seperate server. If you modify a file on 1 server, it will not be replicated to the next.
Azure works by uploading a deployment package. When a new instance needs to come up it uses the deployment package and starts a completely new server.
From a your perspective they don't share anything in common. Because of this you will never know which server you are hitting.
If you have a shared file storage system behind, then it may be a different story. However that scenario looks odd from using Azure. Amazon EC2 with a shared EBS might do it though.
I don't think that I am understanding how CouchDB works. My impression is that everything runs on the client side, so wouldn't that mean it is useless for storing user data because anyone can write a simple script to access that information? This doesn't make sense to me, do I have it all wrong?
Aside from map-reduce and update operations, everything in CouchDB does run on the client. In this context, client means client connecting to the database server, which will usually be an application or script running on your web server. That's the case for other database systems, too: to connect to a MySQL database from a PHP script, you need to use a MySQL client library.
One special thing about CouchDB is that instead of using its own transfer protocol (like other systems like MySQL do), it uses HTTP, which is implemented by almost every single available language out there. This makes the development of a CouchDB client extremely easy.
The other special thing about CouchDB is that its security model does allow you to let end users connect directly to the database. In such a situation, you would write a JavaScript application that runs entirely in the users' browsers and queries the database through AJAX. The server would then authenticate the user and grant access only to those databases that the user is allowed to access, in either read-only or read-write mode. While this requires a bid of server-side scaffolding (to register new users and create a brand new database for them).
But you don't have to. My company uses CouchDB as a general-purpose persistent storage that is completely invisible from the internet, and only our web server is allowed to access it.
There's a really good book on CouchDb here: http://guide.couchdb.org/