I looking for a tool can migrate my users from AspNetSqlMembershipProvider user to WebMatrix.WebData.WebSecurity. I want to host my site on Azure and have a lot of trouble with the AspNet stored procedure.
It seem easy to export data from one table to another but not with the password. How can I do the task It must be transparent for my end users.
Thanks!
If the password is the only obstacle, don't worry. In fact, we cannot and do not need to know the passwords themselves.
In most of the system, the passwords are encoded and saved in a table. In asp.net mvc4 SimpleMembershipProvider, the table is called webpages_membership. In this table, 2 columns are the keys: Password and PasswordSalt. I know nothing about AspNetSqlMembershipProvider, but I think there must be a corresponding table which contains the 2 columns with similar names. Migrating data in these 2 columns should make it work.
I suggest to do it as following:
Create a new account in the old system with a password.
Create a new account in the new system with a different password.
Overwrite the Password/PasswordSalt in the new system by those in the old system.
Try to log in new system with password of the old system.
If it succeeds, it proves that the two systems are using the same machanism then and you can do the whole migration work.
Detailed algorithm can be found here: http://www.jasypt.org/howtoencryptuserpasswords.html
Related
We are a team of tens of data analysts. Our main data back-end is an Oracle database. We use personal schemas to do work where we don't need to collaborate with others and we would like to create schemas dedicated to projects where people need to collaborate.
The problem is that in Oracle, one schema is equivalent to one DB user. If we create a schema dedicated to a project, for the purpose of creating DB objects in the context of that project, there will be a single set of credentials (username + password) that needs to be shared by all team members. This has two inconveniences:
if people mistype the credentials, they can block the account for everyone;
it is no longer possible to monitor who did what for security/audit reasons, since everyone uses the same schema;
An alternative would be that only one person uses the Schema user to create objects and assigns privileges to other people in those objects, but that can become quickly cumbersome.
Another alternative is to interact with the DB through R or Python but that means the credentials will be stored in some text file, which is bad for security.
As we see it, the ideal situation is if multiple personal DB users can create objects in the same schema, and if those objects are automatically available for that set of DB users. Is this totally impossible in Oracle? Is this impossible in any major DB? Is this requirement somehow flawed and as such, there is a good reason for why it is not available?
We could compare this collaboration in a DB schema to what commonly happens with people collaborating in a folder, using R, Python or other programming language for data analytics.
Thank you for your advise!
Maybe I miss something but could you not just create a schema that will be used for all users and grant the required privileges to each individual user?
Each user authenticates with his local account and by default uses his local schema and to access the public one you just use the ALTER SESSION SET CURRENT_SCHEMA command.
We have SAS datasets, for which many people have access to read and write. Many a times user click those tables and open. Table gets locked. To circumvent this problem, I tried to created views in same library, if people double click the view it opens table and locks the table again.
One solution I am thinking of to create view in new library with access=read only option.
Is there read only view option, where in someone double clicks and table does not lock the table. Is it possible to create this view in same library.
I also had to deal with this problem in an environment where we didn't have SAS/SHARE. My solution was to write a batch job that ran at regular intervals doing the following:
Divert the log to a text file.
Attempt to lock the table using a lock statement.
Release the lock immediately if successful.
Parse the log file using a data step.
Extract the usernames of anyone locking the table.
Send an email to all users of the table notifying them that user X was locking it.
Updates to the table only took a fraction of a second each, so although it was possible to catch someone making a legitimate update (or prevent them from doing so), this was very unlikely.
I suggest the best way around this is to create a simple 'data viewer' web application. If you have a mid-tier and a stored process server then you are ready to go, it should only a couple of hours if you have basic javascript / html knowledge.
I wrote a detailed guide for building web apps using SAS in this sgf paper, and a quick summary in this blog post.
The hard part will be convincing your users to use the web app instead of client tools for reading the data!
In the long term it is really best to avoid using SAS datasets and use an actual database instead.
You can create views for those datasets in the same library, but save them to a new SAS folder and give the users read only access to the folder & views. And educate your users about SAS table locks so that they wont get put off if they see lock errors.
If you want users to able to write to those tables, then I recommend having a control framework or process in place.
Example Process:
Users have to submit their code or the data that they want to add / edit,
As an admin you apply those changes in batches / once a week or a day.
Example Control Frame Work:
All tables should be edited / write to using Stored Processes
Create Stored Processes that checks the table lock before edit / write to the tables,
Users will use the SP to write to the tables,
If two users run the same SP at the same time: The second SP to run will see the lock flag and print a message to the user to run the SP again in few mins.
We are cleaning up servers for a customer and have stumbled upon an old application using an H2 database. While the accessing applications have credentials in their configuration files, none of them seem to work.
Even the "sa" user access is not known. As far as I can see, the password for "sa" defaults to an empty string, but access with "sa"/"" is denied (Wrong user name or password [28000-182] 28000/28000 (Help)).
As said, the database is not encrypted. Looking at the file, I can see the SQL statements for the tables, even some table contents.
Is there any way to gain access to that database? As far as my searches have shown it's only possible using the "sa" user. I'm looking for something along the lines of "--skip-grant-tables" from MySQL.
The easiest solution is probably:
Try to login to the database without password. This will fail (wrong user name or password), but it will run transaction log recovery so that the database is in a consistent state.
Then, use the Recover tool (org.h2.tools.Recover) to generate a SQL script.
Edit the script: Change the password for the default user.
Run the script. That way you get a new database.
I have a WPF application with back-end as Oracle11gR2. We need to enable our application to work in both online and offline(disconnected) mode. We are using Oracle standard edition(with single instance) as client database. I am using Sequnece Numbers for Primary Key Columns. Is there anyway to sync my client and server database without any issues in Sequence number columns. Please note that we will restrict creation of basic(master) data to be created only in server.
There are a couple of approaches to take here.
1- Write the sync process to rebuild the server tables (on the client) each time with a SELECT INTO. Once complete, RENAME the current table to a "temp" table, and RENAME the newly created table with the proper name. The sync process should DROP the temp table as one of its first steps. Finally, recreate the indexes and you should be good-to-go.
2- Create a backup of the server-side database, write a shell script to copy it down and restore it on the client.
Each of these options will preserve your sequence numbers. Which one you choose really depends on your skills. If you're more of a developer, you can make #1 work. If you've got some Oracle DBA skills you should be able to make #2 work.
Since you're on 11g, there might be a cleaner way to do this using Data Pump.
Does anybody knows how could I make a trigger or anything else to prevent people to connect on my database with any kind of applications besides mine?
Note that the super-old-and-unsecure trigger to block few .exe such TOAD or watever does NOT really works, since you can just rename the EXE to MyApplication.exe.
Hints?
An easier method would be to move the security to a role that can be enabled only by your application - see a previous answer of mine here
WIth this method another application may create a session but has no other privileges since the role is not enabled.
You may wish to consider Oracle's Secure Application Roles -- it won't prevent people from logging into the database through a rogue application, but it can prevent them from accessing tables and packages if the application doesn't set the role using the password that only it knows.
You can find an tutorial on deploying it here, although to secure it, you'd have to create the role with a password, and your application would have to know the password when issuing the SET ROLE rolename IDENTIFIED BY rolepassword; statement.
I don't know that Oracle has any functionality to help with this (I could be wrong though) so the next best thing might be to write a small server app that lets you have much better control over the login process and acts as the middle-man between the client apps and the database server. That way, all connections to the database come through your server app, and you can control how your server identifies which client app is legit. This will add a bit of complexity to the system though.
If you don't trust the program name in v$session then the only options that come to mind are to have your application encode the password, so that what they type in isn't actually what's used to connect to the DB; or have your app log in with a private username/password and authenticate users against your own users table instead of having Oracle user accounts for them. Both options make management of accounts more complicated though.
When your application logs on, you call a stored procedure that associates the current oracle session as a "trusted" session. Do this by creating a trusted sessions table with a field for sessionID and trusted bit (and optionally a random hash to prevent user tampering).
Create a system wide trigger, that checks the your current session id (and random hash) to detect if it is trusted. If the session doesn't exist in the table, you don't allow the query, and log off the user.
You should also setup a shutdown trigger to clear the trusted session table on exit.