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.
Related
I am trying to create a new user from Oracle SQL Developer. I made a connection with the user Sys and the password that I entered in the installation of Oracle Database XE 18c.
When creating the user I get the error ORA-65096, I have searched the internet and the solution I found is to write the following:
alter session set "_ORACLE_SCRIPT" = true;
However, I want to know if it is possible to create the new user without using any SQL statement or script and do it from the Oracle SQL Developer interface, do I have to login with a different user than Sys to create a new user? or what do I have to do? Could someone give me a detailed explanation please. I am learning how to use this database and I want to try to understand what I am doing.
oerr ora 65096
65096, 00000, "invalid common user or role name"
// *Cause: An attempt was made to create a common user or role with a name
// that was not valid for common users or roles. In addition to >the
// usual rules for user and role names, common user and role names
// must consist only of ASCII characters, and must contain the >prefix
// specified in common_user_prefix parameter.
// *Action: Specify a valid common user or role name.
This implies that you are connected to the root container instead of to a regular plug in database (pdb) where applications should be built. The solution for you is not to overrule setting to enable building an application in the root container but to connect to the pdb that has been made to host your application.
you can check the available pdb's by viewing v$pdbs. The special pdb cdb$root is as the name already tries to tell, the root container. show PDBS will give similar output.
Using alter session set container = [pdb_name]; can be used to switch to your container of choice where regular rules apply.
Even better is to directly connect to that pdb using sqlnet.
My company has a database for vehicle tracking system. And It has a website for user to log on and use.
After I change the sys and the main user password through "ALTER USER --- identified by' command. The website login became dysfunctional. Our DBA just quit so I have no idea how to troubleshoot.
Is there any guideline I can use?
It appears as though the application has the passwords either hardcoded or in a configuration file somewhere. If you can find where that is, then simply changing the corresponding values (ie passwords) should resolve the problem. If that doesn't work, you can try to change the password back to the what they were before using the same syntax you used to make the initial change ... "ALTER USER --- identified by ...
Can possibly be more help if you can tell what web server is hosting your site.
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
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.
We want to allow DB access (Oracle) to our users only through our own application - let's call it "ourTool.exe", installed locally on the users computers. Currently, the users must provide username/password whenever they start "ourTool". The provided password password gets decrypted and we use username/decrypted-password to finally log in to the Oracle DB. This approach prevents the users from directly accessing our DB using third party tools (SQLplus, Excel, Access, ...) and everything in the DB is guaranteed to have been entered/edited using "ourTool".
Now, one of our clients wants to allow its users "single sign-on" (with SmartCards/Oracle PKI). With this, the user will be able connect to our DB without providing any password every time they start "ourTool". But the same will be true for the potentially dangerous tools like SQLplus, Excel, Access, etc.
Is there a way to prevent this? How can we make sure that every record in our DB is only created/edited/deleted using "ourTool" in this scenario?
Since it's your application and you have control of the source, you can use either password protected database roles or Secure Application Roles that are enabled from ourTool.exe. (see http://www.oracle.com/technology/obe/obe10gdb/security/approles/approles.htm ).
For example, with a password-protected database role, the initial connection would be with only the CREATE SESSION privilege, and then ourTool.exe would issue the SET ROLE with password known only to you. Any other application doesn't have the information to set the role. Obviously, the privileges are granted only to the role and not directly to the user in this configuration.
By default, OCI transmits the calling application EXE name and you can access it by querying v$session:
SELECT program
FROM V$SESSION
, which you can do in an AFTER LOGON trigger.
But this can be easily overriden and should not be relied upon.
I renamed my sqlplus.exe to myTool.exe and after making a connection with myTool.exe
SELECT program
FROM V$SESSION
where username = 'SYSTEM';
Returns:
myTool.exe
So be aware, as Quassnoi said: although usable in some circumstances it's certainly not bullit proof.