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.
Related
Is it possible using Custom Credential Provider to make windows logon without real password of local user?
I'm already able to install/register sample code from Microsoft, and even able to debug it.
My expectation from this mechanism: User inputs some password and my implementation performs some comparison against local database of my password (stored as sqlite database).
Reality: local user password MUST be passed to LSA subsystem within
ICredentialProviderCredential::GetSerialization(...)
Frankly speaking I'm trying to use some sort of -one-time-coupon codes as passwords, to login to a kiosk-like workstation.
This is the main reason for developing custom credential provider.
Your provider must return to the Logon UI or Cred UI the authentication information. It can be a login/password pair or a certificate based authentication.
Inside of your database you can store a real user's password and return it after checking your own OTP.
I have an application which has been successfully logging into our database for years without issue.
The password hasn't changed and i can manually login.
I enabled the audit trail in the database and can see the failed login attempt and return code of 1017 indicating invalid username and password combination.
The password being entered in the application is correct but is still being rejected by the database. I confirmed the user and pass combination by logging in with SQL Developer.
Is there any way for the audit trail to show the password being received so that i can find out how the password is being altered between the app and the db.
Are there any other causes to 1017 than an invalid user/pass?
No, the audit trail does not show the passwords of failed log in attempts. Using the audit trail you can determine things such as the machine name and OS user that is attempting to log in, but it will not capture the password that was used.
Since this application has been logging into the database for years, I am guessing that the database itself has been updated a number of times, correct? If so, is it possible that you are running into password case sensitivity issues as a result of an older client being used on the application side? If the application is connecting from a machine using an older client, you may want to check out this question: ORA-01017 Invalid Username/Password when connecting to 11g database from 9i client
To test this hypothesis, you could try logging in from the application side by using quotes to pass the credentials. From the question above:
oracle9i defaults to uppercase as it didn't cater for case
sensitivity. instead of changing the database to insensitive, you can
connect by pasting your password in double quotes eg `sqlplus
youruser/"Password"#db to pass mixed case.
If that is not the case, and you want to determine what password is being passed from the application to rule out that avenue, you could use a tool like Wireshark to listen to the traffic and see if you can sniff out what credentials they're using, assuming they aren't using an encrypted connection. Please only explore this if you have complete control over the network or the permission from the appropriate powers that be, as it could be illegal or against your organizations policy to use a tool like Wireshark without permission.
I am working on an application that uses Oracle OCI to connect to the Oracle database server. The application allows the user to change their Oracle password and uses Alter User xxx Identified By to perform this.
However, this transmits the user's new password in clear text over the network (we cannot use Oracle SSL to encrypt network traffic). I have found that Oracle recommends using the PASSWORD command in SQLPlus rather than ALTER USER, one reason being that the new password encrypted.
Does the OCI method OCIPasswordChange also encrypt the new password when it is transmitted over the network?
This is using Oracle 10 and 11.
Yes, OCIPasswordChange does encrypt the new password sent over the network.
I have now implemented this and done a packet trace. An encrypted AUTH_NEWPASSWORD packet is transmitted to the Oracle database server.
I work as a student web developer for my computer science department and I've been asked to look into a modification of our password reset procedure for linux accounts. Currently users will log in with their university credentials (via Active Directory) and after being authenticated they get a temporary password through email which they are forced to change as soon as they log in. This way eben if the temporary password it intercepted there is a very short time span in which it could even be used.
Now the idea has been posed that instead of using a temporary password that we might allow the user to pick a new permanent password and set it directly through the web utility. It is my understanding that https is more of "the best we have" than "a great way to secure information". Are there any other avenues I can explore for securing the new password so that we can feel comfortable implementing such a system?
Basically, if you communicate with a server over HTTPS and the private key of the server isn't exposed to someone else, you can be sure that anything you transfer (e.g. the new password) can only be decrypted by the server. Additionally the server certificate assures, that the server you are communicating with, really is the server you want to communicate with.
So, using HTTPS provides authentication and prevents eavesdropping.
If you are working with Active Directory, it is my understanding that the Password Modify Extended Operation (which requires the existing password) is not supported. Therefore, the password must be changed with the LDAP modify request. One solution would be to use the UnboundID LDAP SDK with a web application to execute the LDAP modify with the new password. The modify request should be transmitted over a secure connection, or a non-secure connection promoted to a secure connection using the StartTLS extended operation.
see also
AD password change
Using ldapmodify - this article is about the command line utility ldapmodify but the concepts are useful.
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.