We have thousands of users using H2 database, and sometimes, somehow, someone forgets the password.
Is there a way of recovering, at least, the SA user password?
Of course, i tell them that no one would be happy that this would be possible if the database was stolen...
Anyway, i need to be sure, for all the affected users sake.
Thanks.
No, it is not possible to recover the password of any user, because passwords are not stored in the database file. Instead, the password, together with a random salt, is hashed, and only the hash and the salt are stored. The random salt protects against rainbow attacks. By the way, in the server mode, the password is not transmitted - only the hash is transmitted. See the documentation for details.
However, if the database is not encrypted, the data can be extracted from a database file.
Related
I am superuser in postgreSQL, and created passwords for users randomly, and forgot to save from command line. Now, all the passwords of the users that I CREATED are in star form. how can I get those passwords to send to users.
Or if I can't recover that list,or if there is another way to change the all users passwords.
That's not possible. The passwords are hashed with a one-way hash. There is no way you can get the clear text passwords.
The only option you have is to set a new password using \password (in psql) or alter user (in any other SQL client).
I have a website which is vulnerable to SQL injection. It has a username and a password and when we write the username as admin and the password as 'or 1=1-- it logs in saying that you have been successfully logged in as admin. I want to find the password of admin using an SQL injection. What can I do ? Strictly for learning purposes.
I need the password of admin while performing an SQL injection on the username and password fields.
Your ability to retrieve the admin password depends on how the password is stored, and how the server-side script that accesses the database is written. If the password is properly salted and hashed, it is virtually impossible to retrieve it; you're simple overriding the system that checks the password. If not, it would still be very difficult and you would need to do a lot of experimentation (see this answer on Information Security Stack Exchange). Either way, you will need to know a lot about the system and how it works in order to attempt such an attack.
We have migrated our password hashing from MD5 to 512 Hashing on the SQL Server End.
The problem is that each user has a unique hash stored in the database even if the passwords are same(,due to the encryption technique that I cannot disclose).
For The QA guys we have the same password for testing ...after migration to sha512 how can we keep one password hash for all the QA testers??
By design, if you are salting your passwords, this is impossible in normal circumstances as each salt will be unique (assuming your system works as designed). If you manually update the password hash and use a consistent salt (you are using a random salt and storing it with the password, right?), you can all have a common hash.
Why would you want a common hash?
This is one for all you security gurus out there.
I have a SQL Server 2005 database with a database master key, which is encrypted with a very strong password using the server key, which in turn is encrypted using the service account credentials in the Windows Data Protection layer.
I have a certificate which is encrypted using the database master key.
I have a symmetric key using AES256 which is encrypted using the certificate, and I am using the symmetric key to encrypt and decrypt confidential fields in the database.
What does someone need to crack the encrypted fields in the database? My only assumption is that brute force can't be employed due to the strength of the symmetric encryption algorithm, and the symmetric key itself is protected by 4 additional layers of encryption:
Windows DPAPI -> Server -> Database -> Certificate -> Symmetric Key
which seems pretty tight to me.
Let's not include the obvious answer of "get the system administrator's username and password by drugging and sleeping with him", which is definitely relevant but not what I'm after.
Here is a potential attack. It assumes you already have a way to run arbitrary code as the service account. For example, you might exercise a remote code execution bug to get. Having done so, it is relatively trivial to use DPAPI to get the server key. Having done that, you can get the master database key, although you'd need some brute force method to break the password.
It sounds like it would be pretty difficult to do, depending on the strength of the password maybe impossible. Is the service account low or high privileged? If it is an admin account, you could maybe use that (assuming it was broken) to install a keylogger to get the password.
K. Brian Kelley specializes in SQL Server security, and he's written several good articles about how encryption gets bypassed in SQL Server environments, like these:
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-someone.aspx
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/27/a-security-control-inconsistently-applied-is-not-a-control.aspx
http://www.sqlservercentral.com/blogs/brian_kelley/archive/2009/02/20/you-must-trust-your-dbas.aspx
If you're really into security, I'd highly recommend subscribing to his blog. He's also available on Twitter at http://twitter.com/kbriankelley.
Somewhere in memory this un-encrypted key is stored to be able to encrypt against it, is there a way for an attacker to gain access to SYSTEM level to then be able to basically scan memory, or attach an extra thread to MSSQL.
Also, these encrypted fields, are they used in any front-end applications? Are they visible when you SELECT * FROM table? For example, you can have as much security on your database and fields as you want but if someone is able to use an SQL injection to write their own SQL queries and thus view the value of the fields you are still back at square one.
Assuming no human-engineering attacks are possible I would try to attach a debugger to the program reading it, obtain a snapshot of it's memory and try every set of bytes in a brute-force attack.
Even if I couldn't obtain the memory image I would try the same thing with the source file in case the key is in there.
Realistically, you have to ensure the key never appears intact anywhere to defeat such attacks.
I have some data in my user database that I would prefer to be encrypted. Most of the data will need to be decrypted when requested, but there are also passwords that can stay encrypted (in the old days we would use pwdcompare but I believe this is obsolete now).
I have followed the steps here, so I have now successfully encrypted my data.
What I don't understand is the correct way to open the master key at runtime, in order to encrypt/decrypt data. If I want to use stored procedures to retrieve encrypted data, how do I go about opening the master key? Do I pass in the master key's password using a stored proc parameter?
As I have understood, you should create master key once (you can do this during installation process) and this is the first and last time password is needed. After that, using master key create encryption key (symmetric or asymmetric) without a password and use it to encrypt/decrypt your data. You don't have to give a password for it, all you need is use your encryption key and have CONTROL permission on it. The only issue is that your DBA can have it too :)
See this article: Using Asymmetric Encryption and Digital Signatures in a SQL Server 2005 Database