Direct Access to database from native app (any security issues?) - database

I'm new to databases and It's been almost a month I'm working with databases (mostly with MongoDB which is a NoSQL database and I'm loving it :D)
What I am wondering is the security risks you take when you do a direct access to database from let's say a native iOS app.
I know a popular way to this is web service though.
Thanks,
Peyman

I think there're 2 risks obviously:
sql injection.
How to deal with the db password. Just put the plain text in your
config or connection strings?

+1 on password protection or connection strings. Not to mention that your firewall would have to allow every ip through on your database port. People use web services for a reason...in my opinion, don't even consider this an option

Related

Encrypt SQL Server Database Structure

I'm working with my team to build a web application for our customers that uses ( ASP.Net & MSSQL ), we need to encrypt the Database structure to avoid stole the database design.
is't any way to do that, and how ?
Regards,
No, is not possible. You are asking for DRM and SQL Server does not offer any DRM. Any claim to the contrary is snake oil. You simply cannot hide secrets from an local administrator, it will always be able to locate any secret.
If you want to protect IP you must not distribute it to the client, use a cloud based solution.

How to prevent to open MS Access database file?

I am developing one Inventory project to sell by using C# and MS Access. After sell this product, Client(or any other) may open the document and read it. I need to overcome this less secure.
I googled it and found solution that Password protection. But lot of tools there to breach this. Finally I need to close all the ways for steal and view data.
If you feel that the password protection feature of the Access Database Engine (ACE) does not offer a sufficient level of security against unauthorized "snooping" of the data then you really should consider using SQL Server instead of ACE as the back-end database.

Single sign on with SQL Server? Security and performance

I'm working on a website (asp.net c# with SQL Server) and the client is asking for SSO solution. I'm looking to use one shortest implementation where we can create sub-domains for different modules and install/deploy on same or different servers but all of these module/application uses same SQL Server and session is also maintained and shared by SQL Server. However the client is concerned about the performance/scalability and security therefore I would like your advise if you have already worked on such projects and if you would recommend me this solution or anything else.
thank you in advance for your help !
Keep your single sign on information in LDAP. It's definitely the most standardized way to store user information and access. It's really just a database but if scalability and performance are concerns this is your best bet.

Using SQL Server for WSS 3.0 instead of Windows Internal database

There are actually two related questions:
is it possible or advisable to use a full blown stand-alone SQL server for SharePoint Services WSS3.0 instead of the supplied windows internal database it comes with? The client I am working for is asking to utilize their existent SQL server for all WSS content databases to possibly minimize admin effort and improve performance.
As well, would you advise to install WSS on one physical server and the content database on another server? Any gain in performace? Practicality? ect. The default is WSS and all of its databases are installed on the same single server. We don't really need a farm setup of MOSS, because the WSS capabilities are enough for our needs.
Thanks,
Val
Yes, when you create the site check the installation to be a "Web Front End" It will then prompt you to select a location for the SQL database. Just point it to which server you want.
I would definitely recommend putting it on a non-Sql Express instance. The express version only scales to 4 gig, limits the maximum number of connections etc. If your client is going to do much with it at all, you will eventually hit that limit. Full blown sql server has other advantages too, like help with backups etc.
Yes and yes.
Keeping the SQL and WSS servers separate saves resources on both, and neither are light weight applications. It also allows you to easily begin clustered/distributed environment in the event your usage increases, as well as following a least privledge principle, keeping product patches separate, etc.
As an addendum, you say you don't need a MOSS farm because WSS fits your needs, but be aware that it's just as easy to setup a distributed WSS environment as is MOSS; MOSS only adds capabilities to the application. It's usually a good idea to have at least two WFE's in the farm, if for nothing else than redundancy in case of failure.
Yes you can use a 'full blown' SQL Server instead of the the free and limited SQL Server Express that is delivered with Windows SharePoint Services 3.0 (wss 3.0)
It's even better to separate the database and the actual website! More scalable (if you upgrade to MOSS), easier to manage and less security risks.

Web interface for SQL Server database

I have been working on VB6 database desktop programming, but now a client is asking for a
simple web interface (some inserts into SQL Server db used by a desktop application).
The question is: Which approach is better?
1)creating asp.net project, connected directly to the SQL Server database;
2)creating separate (simple) mysql database managed by php and synchronization (in 15 minutes for example)
Thanks.
Personally since you already have the SQL Server database, I see no reason whatsoever to add the complexity of another database and then synchonization. The first alternative is simpler to create and can be secure if you design it correctly. The issue about hosting is irrelevant since you are going to your own database that already exists, so is the issue about cost since the databse is already there. Further since you are already supporting SQL Server, you may be able to reuse some code rather than write new code (mysql's version of SQL is not the same as SQl Server's version). Synching the two databases may be more complex than you think (differnt data types, etc.) and the data in the real database is not real-time whereas with the first alternative it is.
I'd prefer the separate database approach.
It's more secure.
PHP/Mysql hosting is widespread
You can pretty much achieve anything with the technologies available, it just depends on your skill and productivity with specific technologies and the availability of online help. Plus Microsoft stuff you tend to have to pay for whereas PHP/MySQL is totally free.

Resources