I want to open key3.db in SQLite browser which store the key for encryption of saved password in firfox, but I see this error: "File is encrypted or not a SQLite3 database or encryption key does not match"
I think key3.db is encrypted. Can anybody tell me what is the Encryption key of this database?
It is not encrypted, it is stored using firefox's .db format (shows up as a Berkeley db according to "file"). Thunderbird pass decryptor will decrypt this value.
Additional reference
Related
Am conducting a penetration test on Oracle flexcube direct banking solution. I managed to retrive a users login dump from the system however the fldPassword value is encrypted.
If i have the fldPassword=value and fldEncrKey=value. How is it possible to decrypt fldPassword?
Oracle FCDB user's password can't be decrypt back because FCDB password encryption/hashing is a one-way trip. During authentication the plain input password decrypt and compare with the stored fldPassword.
When I import a public/private pair into windows certificate store, Windows does not require any password of any kind to encrypt the keys.
From that I conclude that if it is a user's store, it uses the user's password (or probably the user's hashed password) to encrypt the private key, and, if it is the local machine store, it is probably some kind of hardware-based key to encrypt the private key.
Did I get it right???
And if I did, what is the point of non-exportable keys if I can decrypt the keys???
And last question - If I got it right up to here, what are the alternatives?
As "SLanks" link explains, the private keys are encrypted with the user's password or the machines's password (depends on the location of the keys in the store).
Therefore, anyone who can log to the machine can obtain to this user's keys and anyone who has access to the machine can obtain keys stored for the local machine.
I'm trying to figure out how to Windows credential roaming is implemented. I have found that it will roam certs that have been strongly protected with a password (optional entropy to CryptProtectData()).
I can't see how this could be done unless Windows keeps a copy of the password somewhere when the cert is imported. Copying the files in %APPDATA%/Crypto/RSA{UserSID} to another machine would not work as the keys are encrypted with the users DPAPI master key and optionally a password.
Other than using ProcMon and I have no idea what else to try or look at in order to figure this out. Any pointers to help figure this out would be much appreciated!
CryptProtectData does a little something more that makes the whole thing possible.
DPAPI will generate a key for encryption. The DPAPI key will then be encrypted with another key derived from your password.
What is sent in credential roaming is the DPAPI key, not your password.
It is the same thing that also allows DPAPI to keep working (locally) when you change your password. Otherwise, Windows would have to track DPAPI encrypted blobs stored everywhere (files, registry keys, etc.) to encrypt to the new password derived key. There is an infinite number of applications, making it impossible.
Instead, the key is in one well known and well hidden location, never seen by the user. Windows can easily rencrypt the DPAPI with the new password, shielding applications using it from password changes.
The same mechanism is also used by credential roaming to stay indenpendent of the user's password.
This website has code to extract the SYSTEM's account DPAPI key, and some information about the structure, it might help you debugging.
When you use the Oracle JDBC client library to make an Oracle connection, is the password or the security-handshake encrypted by default? (Want to know if there is a risk that the password can be sniffed over the wire when making a connection using the Oracle JDBC client library)
The password is always encrypted when in transit over the network.
That is not to say that it is impervious to attack. If an attacker can obtain the hash of a user's password and they can monitor network traffic between a legitimate client and the database, then it is possible to obtain the plain-text password.
For the curious, here is a summary of the authentication process across various versions of the Oracle database software. The steps dealing with the transit of the encrypted password are in bold. It is not entirely intuitive which version of the authentication protocol is being used by the JDBC driver because it doesn't always match its advertised version. This is because the client can negotiate which protocol it wishes to use. For example, the 11g JDBC driver may not necessarily use the 11g authentication protocol when connecting to an 11g database (it may fall back to the 10g authentication protocol). I forget which drivers use which protocols.
Authentication protocol in Oracle Database 8
The client requests a server session key for a particular user.
The server generates a server session key.
The server encrypts the server session key using the requested user's password hash as the secret key.
The server transmits the encrypted server session key to the client.
The client decrypts the encrypted server session key using the user's password hash as the secret key.
The client encrypts the user's password using the server session key as the secret key. (proprietary algorithm based on DES)
The client transmits the encrypted password to the server.
The server decrypts the encrypted password using its server session key as the secret key.
The server computes the hash of the decrypted password.
If the computed password hash (from step 9) matches the copy stored on the server, then the user has provided the correct password.
Authentication protocol in Oracle Database 9i
The client requests a server session key for a particular user.
The server generates a server session key.
The server encrypts the server session key using the requested user's password hash as the secret key.
The server transmits the encrypted server session key to the client.
The client decrypts the encrypted server session key using the user's password hash as the secret key.
The client encrypts the user's password using the server session key as the secret key. (proprietary algorithm based on DES)
The client transmits the encrypted password to the server.
The server decrypts the encrypted password using its server session key as the secret key.
The server computes the hash of the decrypted password.
If the computed password hash (from step 9) matches the copy stored on the server, then the user has provided the correct password.
Authentication protocol in Oracle Database 10g
The client requests a session key from the server, specifying which user it wishes to connect as.
The server generates a server session key.
The server encrypts the server session key using the requested user's password hash as the secret key.
The server transmits the encrypted server session key to the client.
The client decrypts the encrypted server session key using the requested user's password hash as the secret key.
The client generates a client session key.
The client combines the client session key with the server session key.
The client salts the user's password.
The client encrypts the user's salted password using the combined session keys (from step 7) as its secret key. (AES-128)
The client encrypts the client session key using the user's password hash as the secret key.
The client transmits the encrypted client session key and the encrypted, salted user password to the server.
The server decrypts the encrypted client session key using the requested user's password hash.
The server combines the client session key with its server session key.
The server decrypts the encrypted, salted password using the combined session keys (from step 13) as the secret key.
The server un-salts the salted password.
The server hashes the decrypted password.
The server compares the computed password hash (from step 16) with the stored password hash. If they are equal, the user has provided the correct password.
Authentication protocol in Oracle Database 11g
The client requests a session key from the server, specifying which user it wishes to connect as.
The server generates a server session key.
The server generates verifier data.
The server encrypts the server session key using the requested user's password hash as the secret key.
The server transmits the encrypted server session key ("AUTH_SESSKEY") and the verifier data ("AUTH_VFR_DATA") to the client.
The client hashes the user's password using the verifier data as the salt.
The client decrypts the encrypted server session key using the user's password hash as the secret key.
The client generates a client session key.
The client combines the client session key with the server session key.
The client salts the user's password.
The client encrypts the user's salted password using the combined session keys (from step 9) as its secret key. (AES-192)
The client encrypts the client session key using the user's password hash as the secret key.
The client transmits the encrypted client session key and the encrypted, salted user password to the server.
The server decrypts the encrypted client session key using the requested user's password hash.
The server combines the client session key with its server session key.
The server decrypts the encrypted, salted password using the combined session keys (from step 15) as the secret key.
The server un-salts the salted password.
The server hashes the decrypted password.
The server compares the computed password hash (from step 18) with the stored password hash. If they are equal, the user has provided the correct password.
I want to encrypt passwords using the DPAPI like this
ProtectedData.Protect(plain, optionalEntropy, DataProtectionScope.CurrentUser);
and wonder if the domain administrator could decrypt the generated blob, as
Using Passwords Effectively states:
However, in a domain environment a
domain administrator can safely change
your password, and you'll still have
access to your encrypted files.
It seems like the domain administrator would have to decrypt the data (or rather, the encrypted master keys) first, in order to be able to re-encrypt it using a different password.
The answer is yes, provided he also has acces to the entropy key(if one is created), or if he is willing and capable enough to hack into the blobs (see links below).
For the Master key in DPAPI (in CurrentUser mode), the windows login username and password are used to generate the master key.
If the administrator updates the user's domain password, DPAPI wil reencode the master key for that user. The same goes if the user updates his password due to eg. a monthly password change policy.
However, if he doesn't have access to the optional entropy key or the data that composes that key, the file will remain encrypted and all he will get is invalid data.
If DPAPI is used in CurrentMachine mode, the file can only be decrypted on the computer that encrypted it, however the file will be readable to all accounts on that computer, again provided they can also muster the content of the entropy key.
A good repository for information is DPAPI Secrets and this paper on reverse-enginerring DPAPI + link to a tool that can recover data from DPAPI blobs
Short answer : he probably can't right out of the box, but Domain Admin is powerfull. There are many ways they can get to your key if they really want it.
Long answer : DPAPI encrypts your data with a key. IIRC, it uses AES with a key that changes every 90 days. The key is stored on your computer, encrypted with your password. That's the default and it saves your key out of reach of anyone but you.
Unless your domain admin remotely installs a key logger, steals your password, impersonnate you and steal your key (or go straight to the data which he now sees in plain text).
Another somewhat less known fact is that when Credential Roaming is enabled on Active Directory, it will send your encrypted keys to a server. A domain admin could use that copy for an offline attack. But it is hard and unless your data is very valuable, I woulnd't worry about it.
The answer is yes. PoC utility with description: Vulnerability of DPAPI data protection in Win2K, Win2K3, Windows Server 2008, and Windows Server 2012
Works in Win Server 2016/2019 as well.