I am working on an security analysis for an DB2 setup which uses federated nicknames.
When setting up federated nicknames on DB2 a wrapper and user mappings must be created. For both a username and a password must be stored at the DB2.
CREATE SERVER V9SAMPLE TYPE DB2/UDB VERSION 9.1 WRAPPER DRDA
AUTHID "USERNAME" PASSWORD "PASSWORD" OPTIONS ( DBNAME 'SAMPLE' );
CREATE USER MAPPING FOR USER SERVER V9SAMPLE OPTIONS
( REMOTE_AUTHID 'USERNAME' REMOTE_PASSWORD 'PASSWORD' );
Can anybody tell me how DB2 stores this credentials internally and if there is any way to read AUTHID and PASSWORD from the database?
I would exprect that they must be stored in plaintext as they must be send to another Server as login credentials. But that could open attack vectors as Mallory could recover the credentials.
Are there any security measures that must be applied to protect the passwords saved for use with wrappers and user mappings?
from this manual page https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.data.fluidquery.doc/topics/cfpint11.html
By default, the federated server stores user mapping in the SYSCAT.USEROPTIONS view in the global catalog and encrypts the remote passwords.
SYSCAT.USEROPTIONS is a view, and shows passwords as "********". Look at the underlying table to see the encrypted value. E.g.
db2 "select SUBSTR(SETTING,1,20) from SYSIBM.SYSUSEROPTIONS WHERE OPTION = 'REMOTE_PASSWORD'"
1
--------------------
A����-�;YAS����
The page above also says
As an alternative, you can use an external repository, for example a file or an LDAP server, to store user mappings. To provide the interface between the federated server and the external repository, you create a user mapping plug-in.
and see the section "Security for federation" to read more details about the options for securing federated systems
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.data.fluidquery.doc/topics/iiyvfed_security_fed_sys_l1.html
Db2-LUW wrapper-password and user-mapping passwords are stored encrypted (not in plain text). The cipher can be version specific. You cannot view a plaintext at-rest password in the database.
As regards the federated passwords on the network, this depends on the target environment. Db2 has different options for this, from password-only encryption, to password and data encryption, to TLS - all of this depends on the chosen configuration items. So the federated-passwords on the LAN do not need to be in plaintext unless the target environment is unable to handle encryption or the relevant wrapper does not implement the required encryption.
Related
Is there anyway that we can give security measures for nifi, like any username and password for the nifi UI page. And also anyway to give storage for the configuration made in the NIFI UI page.
Need some suggestion on this issue.
All user authentication and authorization mechanisms are only available once TLS is enabled. This was an intentional design decision because entering sensitive user credentials over a plaintext HTTP connection is unsafe and exposes the user to many opportunities to have those credentials, which unfortunately they may reuse for other services, stolen.
After enabling TLS for the NiFi application, LDAP, Kerberos, OpenID Connect, Knox, and client certificates are all available as authentication mechanisms.
With the default settings you can point a web browser at
https://127.0.0.1:8443/nifi
The default installation generates a random username and password, writing the generated values to the application log. The application log is located in logs/nifi-app.log under the installation directory. The log file will contain lines with Generated Username [USERNAME] and Generated Password [PASSWORD] indicating the credentials needed for access. Search the application log for those lines and record the generated values in a secure location.
The following command can be used to change the username and password:
$ ./bin/nifi.sh set-single-user-credentials <username> <password>
My Java app for Windows requires uploading results to a server using an ftp client. Currently, I have the port, sever URL, username and password in an ini file that the app installer places on the users computer. I'm concerned that a user can easily open the ini file and see these credentials and thus be able to log in to my account on the server. I'm considering encryption of the username & password. Or, just ask the user to provide his/her own credentials, perhaps using Google or other free outgoing service? Are there better ways of handling this?
With SFTP, a connection can be authenticated using a couple different techniques one of them involves using Public / Private Key Pair.
With key-based authentication, you will need to generate a SSH private key and public key beforehand. If you want to connect to a partner's SFTP server, you would then send your SSH public key to them so they can load onto their server and associate with your account. Then, once you've connected to their SFTP server, your client software will transmit your public key to the server for authentication. If the keys match, along with any username/password supplied, the authentication will succeed.
Finally got back to this issue, and here's what I've learned.
First, I've decided to provide FTP access on my hosting server with a "home" directory so the user can't access site data other than his own. I will provide the username and password to the user. Second, the username will be stored in the Windows app database. Third, neither the password or a SaltHash of that password will be stored in the database. Thus the user must type in the password on each FTP upload.
The reason for not using SaltHash because is it's pointless. I.e., if I did go to the trouble of creating and storing a SaltHash, the user would still have to type in a password. That entered password could be salt hashed and compared with the stored SaltHash to be sure it's valid but that's no better than getting an acceptance or rejection from the server.
Or, what am I missing?
A financially regulated business partner would like to understand some of the details of how a user's password are maintained (hashing algorithms etc) in Azure AD B2C. Can anyone share any insight on this.
I can find information on how Azure AD syncs passwords on articles like this https://www.dsinternals.com/en/how-azure-active-directory-connect-syncs-passwords/ but not how a cloud based password is secured.
Thanks Michael
Azure AD B2C is just active directory in the backend. See this blog post for how it handles passwords:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/034a0e33-a8ab-474e-ba6c-3371724d0be1/forum-faq-how-is-user-password-of-user-objects-stored-in-active-directory-can-i-view-it-can-i?forum=winserverDS
Excerpt:
The users' password hash is stored in the Active Directory on a user object in the unicodePwd attribute. Instead of storing your user account password in clear-text, Windows generates and stores user account passwords by using two different password representations, generally known as "hashes." When you set or change the password for a user account to a password that contains fewer than 15 characters, Windows generates both a LAN Manager hash (LM hash) and a Windows NT hash (NT hash) of the password. These hashes are stored in the local Security Accounts Manager (SAM) database or in Active Directory.
This unicodePwd attribute can be written under restricted conditions, but it cannot be read due to security reasons. The attribute can only be modified; it cannot be added on object creation or queried by a search. In order to modify this attribute, the client must have a 128-bit Secure Socket Layer (SSL) connection to the server. For this connection to be possible, the server must possess a server certificate for a 128-bit RSA connection, the client must trust the certificate authority (CA) that generated the server certificate, and both client and server must be capable of 128-bit encryption.
I have a funny feeling this is something Microsoft will never tell you for security reasons.
You cant even recover a password from Azure AD
I am using Microsoft Access 2010 with unbound forms. No linked tables allowed, otherwise the connections string is stored in the table definitions. So it follows that we will use a query definition with no name to access SQL SERVER. This is recommended by Microsoft. We need to get the connection string from somewhere though. So it is recommended to return it from a method with a obfuscated name. It is recommended not to embed the connection string in plain text in the application source. So we use encryption.
A good way of doing this is to require the applications administrator to define the connection string at the first run of the application and according to this msdn article
...encrypt its value via DPAPI with a user-specific key of the account under which the application runs, and save the encrypted value in the Windows registry.
The accde launches from the logged on windows user account, after which the apps admin can login and setup the connection to the database, following the recommendations above.
The weakest link i now seem to have is the windows user account. It seems that anyone logged in to that account could decrypt the connectionstring if they knew the implementation of the security scheme. Which means that the system still is not secure enough.
I could create a new windows user, but that would mean that the password for that user must be kept safe, which means we are back at square 1, securing the password that is used to access some secret information.
There must be an easier way, any ideas?
Is there a reason you need to persist the connection string from session to session? Could you instead build a log-in form in your application where you accept the user's credentials, server instance and database name that they will be connecting to and keep this information in memory while the application is running?
This might provide more flexibility in that the administrator could decide to move the database to a new server and wouldn't have to worry about decrypting the connection string to change it and re-encrypt it. It would also allow for multiple databases to be defined - I'm thinking of a situation where you would have a QA server defined for testing changes before rolling out to the production server.
I need to implement the Win2k3 password validation policy. As my application resides on Win2k3 cane we validate the password directly with windows domain password by using LDAP. This is because application design does not want to store 8/more password entry into DB and validate new password against that. As Windows already does same thing and using LDAP we can lookup into windows server.
Can any one please let me know LDAP API to fulfill above requirement in VC++.
There is an API that Secure Ops, Novell's Identity Manager, and other products use to plugin to the password change functionality. (I do not know the API name, sorry).
It requires a password filter installed on each domain controller, since the only time it can catch the clear text password to try and do anything with it is when it is being changed, and it might be changed on any given DC at any moment in time.