I have a requirementto automatically create some SQL data which will contain PBKDF2 encrypted data within it
I can see there are ways to implement this hash using CLR - is there anyway to implement it simply through SQL (T-SQL or stored procedures)? Environment restrictions do not lend themselves to allowing me to implement using CLR
Any help greatly appreciated
Thanks
Related
I am planning to encrypt my table column data with DB2 provided encryption functions. In this case the suggested option was to use DB2 ENCRYPT Scalar function. However, IBM documentation suggests this function is deprecated. Also, it uses RC2 block cipher algorithm which is considered weak.
Kindly suggest any alternate function for the same, which can be used to encrypt the data.
I tried to search the alternative for the same but couldn't find much help.
You seem to be referring to Db2 11.5 and its ENCRYPT function. Db2 offers built-in native encryption. It encrypts data at rest and the scope is the database. It is the recommended way if you want to use an encryption offered by the product itself. The documentation has an overview for data encryption, discussing all available options for data at rest and data in transit.
If you only want to encrypt single values, you could also implement your own scalar function (as UDF).
I publish this post in order to reveal the underlying idea of the real use of this tecnology.
I know this isn't a common question, but it doesn't mean that it isn't important.
If you were trying to work with lots of tables of a Database, and you were using lots of BPEL Services, would you choose SDO (Service Data Objects) instead of DBAdapters (DataBase Adapters)??
I have been working for few weeks with SDOs and I find these really useful, but I'm not sure if the use of SDOs is better than DB Adapters or not...
What do you think about this?? SDOs or DBAdapters??
Thanks in advance.
Basically SDO is Oracle SOA's attempt at an ORM and therefore you can simple look for information on ORM compared to JDBC. The DBAdaper is slight different from plain JDBC in it has extra features around polling and stored procedure integration.
DBAdapter for -> Simple SQL, Stored procedures, basic read write, delete and update and polling
SDO -> Highly reuseable code and everything that doesn't suit DBAdapter.
Here is a thread to look at http://forum.spring.io/forum/spring-projects/data/14117-jdbc-or-orm-framework-what-are-the-pros-and-cons
I created two methods Encrypt() and Decrypt() in my Web Application for Encrypting and Decrypting Data.
Now, I want to use same technique in my SQL Server Database for Decrypting Data.
Can anyone tell me how is it possible.
Please help!!
Thanks,
Rahul
Even though is theoretically possible to load your functions as SQLCLR, you will get key management wrong. Use SQL Server cryptographic functions and discard everything you wrote yourself. Use a proper key hierarchy.
I am evaluating the SQLite database for my requirement. Does SQLite support stored procedures?
If yes then what are the limitations? Does SQLite support the range?
No, it does not. See Appropriate Uses For SQLite on the main site.
A key reason for having stored procs in a database is that you're executing SP code in the same process as the SQL engine. This makes sense for database engines designed to work as a network connected service but the imperative for SQLite is much less. Given that it run as a DLL in your current process it makes more sense to implement SP in the client language.
You can however extend SQLite with your own user defined functions in the host language (PHP, Python, Perl, C#, Javascript, Ruby etc). I've done this in C# using DevArt's SQLite to implement password hashing.
If you really want to store SQL code in the DB (such as when you want to develop cross-platform apps), you can create a specific table that will store raw SQL commands that do the thing, then in the client you obtain the SQL command. e.g.
var myString = db.CreateCommand("SELECT SqlColumn FROM tablewithsqlcommands WHERE Procname=theprocedureIwant").ExecuteScalar();
and then execute it in the second step
var myResult = db.CreateCommand(myString).whatever_execution_method_you_need();
Is it a best practice to use stored procedure for every single SQL call in .NET applications?
Is it encouraged for performance reasons and to reduce surface area for SQL injection attacks (in web applications)?
Stored procedures have a few advantages over parameterized queries:
When used exclusively, you can turn off CREATE, INSERT, SELECT, UPDATE, ALTER, DROP, DELETE, etc access for your application accounts, and this way add a small amount of security.
They provide a consistent, manageable interface when you have multiple applications using the same database.
Using procedures allows a DBA to manage and tune queries even after an application is deployed.
Deploying small changes and bug fixes is much simpler.
They also have a few disadvantages:
The number of procedures can quickly grow to the point where maintaining them is difficult, and current tools don't provide a simple method for adequate documentation.
Parameterized queries put the database code next to the place where it's used. Stored procedures keep it far separated, making finding related code more difficult.
Stored procedures are harder to version.
You'll need to weigh those costs/benefits for your system.
No.
If you send your queries to SQL Server as parameterized queries, SQL Server will cache the execution plan AND will sanitize your parameter inputs properly to avoid SQL injection attacks.
I prefer stored procs over inline SQL, because this way the SQL is one consolidated place; however, I prefer using a tool like nHibernate which will auto generate the SQL for me, then you have no SQL to worry about!
There is one more advantage - when it comes to tuning, especially per customer, it can be easily done with SP (by adding hints or even rewriting the code). With embedded SQL it is practically impossible.
It's just one way of doing things. Upsides include keeping all your SQL code in one place, procs being verified for syntax at creation time, and being able to set permissions on procs, which usually represent some kind of "action" and are well suited to a conceptual security model.
Downsides include massive numbers of procs for any medium or larger application, and all the housekeeping that comes with that.
My employer's product uses procs for everything, and I must say with the right practices in place it's quite bearable.