I have a project running in vb.net. It's currently a very small project, so I have used XML serialization as the main way of storing information. I.e. creating a xml file in the .exe folder. and saving/reading from there.
Problem: Since the project is small, I have no SQL database setup and I would like to keep it that way. But I do want to create a user/password for access to the program.
What I have tried: I have tried using XML serialization, but hiding the xml file. Once I hide it, I'm unable to access the file (saying I have no permissions).
What's a good way to have the same utility without using SQL and not giving away security?
Hiding the file is pointless. You should simply hash the passwords and then store the data just as you do for any other data. That's exactly what you'd do if you were using a database too. When a user registers, you hash the password they provide and store the result. Anyone can then view the data without breaching security because they cannot get the original value from the hash. When a user logs in, you hash the password they provide and compare that to the value in the database and, if they match, the user is authenticated.
You should do some reading on hashing in general and also consider adding a salt for extra security, although that may not be worthwhile in this case.
Related
In a VBA project, I have a large SQL query that I retrieve into a string variable to form part of an operation to retrieve data from a remote database.
At present, I am storing this in plain text in a file, and I retrieve it from that file when needed.
Whilst this makes development/updates easier because I can readily edit the query in the file, it does present an exposure because a user could edit the file, possibly maliciously (limited opportunity for damage, but an unacceptable security exposure nonetheless).
The options to mitigate this risk that I am considering/have considered are:
store the text inside the project, as a global variable. Good because it's not exposed to the user, but unfortunately this means every time I need to make changes to the query, I have to transform the query into chunks, escape quotes, use line continuation, add line feeds and concatenate each chunk together. Yuk.
store the text in a module wrapped in directives not to compile it, then use VBE methods to retrieve and parse the text in from the module lines. Better than above but requires VBE to be enabled by end-users. That counts this option out.
keep the text in an external file, but obfuscate it (e.g. Base64 encode it). Adds some (acceptable) overhead for edits to the file, but requires a base64 decoding method in the project (does VBA have one?).
as above but use encryption of some kind - again, needs a decrypting method in the project.
store the text in a securable file-based format (eg .mdb or .accdb) and code credentials into the Visio project to retrieve the text.
Any recommendations or experiences? Have I missed some straightforward option that VBA offers?
Why not store the query string in the remote database and retrieve it when you need it? You can maintain the string in that database and use the database [read-only] protection to prevent ordinary users from altering it.
The table could look like TABLE QUERYSTRINGS (QueryName, QueryString).
The query could be "SELECT QueryString FROM QUERYSTRINGS WHERE QueryName='MyQuery';"
May I suggest another solution? Keep in the "very hidden" sheet.
Copy the SQL query to a sheet (one row, or many, up to you); then go to the VBA (macro editor, IDE, however you call it) and in the project menu select the sheet; finally in the properties window (press F4 if you cannot see it), select:
Visible = 2 (xlSheetVeryHidden)
That way a user will not see the sheet and the code, and as long as you protect the project with a password, the user will not be able to access it.
I'm using Play 2.1.x and I'm wondering if there is a way to encrypt passwords that might be needed for database access? I have a configuration entry that stores the database server url, user credentials for accessing the database and I do not want to leave my password as plain text. How can I have my user credentials encrypted? I want to later un-encrypt when I use them within the context of my Play server. Any pointers?
The problem is where would you store the decryption key. If you store it in the same (or similar) configuration file, the entire exercise is moot.
I am guessing that you do not want to put the plain text password in application.conf to avoid having it show up in version control system. One way of mitigating that kind of leak is to have a different store for sensitive configuration files for production systems (a different repository that has fewer accessors works nicely).
This is my first time that I am working on a big project for a client. So I was not sure how to solve this problem. However I have come up with two different ideas but I need professionals opinion about which one is better :)
Situation :
There is an application which runs on different client's iPad. Application data is stored by using giant XML file. This XML file is shared among all client by a server. So a server has a centralised copy and each client has their own copy. Once client made changes to their XML copy they updates server copy in and other client updates their copy by updated server copy.
Now only one client can make changes at one time, To fix this I have logic by which before client starts editing XML they need to get ownership from server and server will only allow one client to edit at one time.
Visual Representation :
Now on client side I have to think of a logic by which I will update my client copy and upload it to server. There are two options,
Option 1 :
In option 1, I can directly manipulate XML file by using GDataXML parser and upload that copy to server. For persistence I can save client copy on my iPad in document directory.
Option 2 :
In option 2, I can read XML file create a CoreData representation for local storage. When ever I update data inside core data it will I will change XML file too and than upload that file on server. Double work but I guess better persistence.
Now which one more robust and advisable? Personally I was planning to do option 2 because it seems more robust as I am persisting application data in core data. But option 1 seems more easy work but I don't know how good persistency will remain.
Sorry for lengthy question,
Thanks for any input given.
There are a number of factors which would influence selecting the second option over the first.
How big is the XML file? If you need to work with very large documents, you may need to incrementally parse the XML (SAX) into core data. This will allow you to access the document's contents without loading it all into memory at once.
Do you need to run complex queries in the data? If so, you may be better off using core data fetch predicates, rather than xpath or XSL.
Are you already using core data? Depending on how the XML data is structured, it might be simpler overall to import the data into your existing persistent store.
Otherwise, you can probably make due with parsing the entire document and either traversing the resulting tree or querying with xpath.
If you need to create an object graph based on what you get from server and show it to user (which you most probably need to do), you should stick up to second option, since it allows easy and robust data persistence.
If you do not need to present user with any data from the XML file you can, of course, store it in the Documents directory.
So, if this is a client application and it has at least some visual representation of the data from an XML file you should use CoreData.
If you want a regular update of data , then use CoreData
How is authentication handled in CouchDB? Say I create Admin users and Readers, and assign them roles. Say also that I assign them to an individual database. On the file system level, is there a way for someone who is not authenticating, to look at the data that is stored in the database? Is the data stored as plain text in a file? How is this handled in CouchDB?
Through the database interface, roles are just as strong as they are in any other database. As long as they can't get hold of the files, it's absolutely as secure as your permissions and passwords. However, if they do, there's absolutely no compression or encryption built into CouchDB. Encrypt the data in your code (or your abstraction layer if you use one) if file system access control is a concern - of course anyone who gets hold of your DB filesystem could probably find your code's decryption keys, as well.
It's not a plain text file, it's a binary file that combines the data and indices, but you could copy it to a local CouchDB install and view it that way, or just open it in a good text editor. The data chunks are stored in plain text (JSON, actually) and isn't hard to read, though binary attachments remain binary.
in my Mac software I need decrypt a file and, after I do my operations on it, I will remove it. My problem is: Where can I put this file? I don't want show it to the user.
The following API will give you a directory path that is "out of the way":
NSTemporaryDirectory();
Do you mean "decrypt a file in a place the user can't access?" Any place your app can write to, the user can see. And in theory, a user can access any bit or byte on a computer to which they have physical access.
There are obfuscations and such that reduce the odds a user will come across sensitive data, but they are meant for particular situations.
Can you tell us more about your end goal here? Are you trying to implement a DRM/copy protection scheme? Are you trying to prevent cheating in a game? Do you just not trust your user? What?
I think your best bet would be to keep it in memory.
If that's not an option, it depends on what you want to do with it. It's possible you can open a temporary file, and immediately delete it - keeping the valid filehandle open, but not keeping a link to it on the disk.
Another option, perhaps - can you get your secondary program to read from STDIN or a pipe? You could then decrypt the file and pass it's content via a pipe? Clearly, the more complex this process is, the more weak links it might have, but sometimes you just have to get things working.