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
Related
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?
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.
I want to write a daemon service to visit customer office 365 resource by application identity, from document i found there are two ways to support it one is https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds and the other is https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-certificate-credentials. I want to know what's the different between them and which is the beat solution to implement a daemon service.
thanks
Based on my understanding, the only difference between them is that certificate credential provides a higher level of assurance. For example, you can control the expired time of the client_assertion you generated flexibly. Even it is leaked, the damage will be minimized based on the lifetime of client_assertion.(This is only suppose that HTTPS is not security). If the shared secret was leaked, we will not able to limit it before we detect it and disable the secret.
More detail about client credentials flow, you also can refer link below:
Service to service calls using client credentials (shared secret or certificate)
I have created an app which serves as a bridge between 2 different APIs - WebEx & Exchange Web Services - and Email. A user sends a calendar invitation to a special email address, the app parses the ICS and creates a WebEx Meeting, then connects to Exchange Web Services and puts the WebEx invitation information into the original invite.
This was created since WebEx does not have Mac Email/Calendar integration.
The rub is that to use WebEx API and Exchange API, I obviously need credentials for both APIs. I securely store the credentials with AES 256 bit encryption in the DB, but to access the APIs, I need original plain-text credentials (no oAuth or token support in APIs). They are securely transmitted over SSL, of course.
The security risk is not in having the passwords stolen as encryption keys are stored safely. The issue I am looking to address is the fact that customers fear their enterprise credentials are now stored in a manner that allows someone with access to those keys -- me or someone on development team -- to decrypt their information and gain access to the credentials.
The value of the app is great -- it saves tons of time, but how can I protect against this fear, while still allowing for this approach to work?
The reality is if your code needs to send the passwords then if a developer has the source code and the encrypted passwords they'll have access to the plain test passwords. The only way around this is to deny the development team access to the encrypted passwords and deny those with the encrypted passwords access to the source code. You accomplish this by keeping the dev team away from the production database.
The security risk is that you have access to the production database storing the keys. Eliminate that access and their concern should be eliminated. Provide a utility (desktop or web-based) that can be used to configure the keys - a good idea anyways since those passwords will need to be changed in the future.
Have the customer create a database and then point the app to the database through a connection string change. The customer can use the utility to set the passwords.
I have a Silverlight 3 app which connects to a server to perform various actions. My users log in using Forms Authentication but the actions they request are run on the server using the AppPool account so when they go in the audit logs they're recorded against the AppPool account. PCI DSS regulations now require that the user's own ID is in the audit logs which means the action must be taken using the user's creds. Now, I can save the user's creds when they log on and submit them with each request and the actions being taken by the server can use those creds. But the PCI regs say that if creds are saved they must be encrypted (to avoid someone taking a memory dump of the PC and getting the password).
The only way I can see of doing this is to get a public key from the server and encrypt the password with it, then submit the encrypted password and decrypt it on the server using the private key. But Silverlight doesn't have asymmetric cryptography.
I guess I'm too close to the problem and there must be another solution but I can't see what it is. Can anyone help?
CLARIFICATIONS
It's an internal application. Up until now, I've been using IIS Forms AuthN over SSL to Active Directory - I'm not worried about protecting the password in transit, just whilst it's held in memory on the client. As I understand it, because I'm using Forms Authentication, impersonation is not possible on the server unless I use LogonUser, which means I need the password on the server, so I need to transmit it each time, so I need to hold it in the client, in memory, until the app closes.
Are you saying you need to store the password for re-use in the silverlight app? If you are concerned about the password appearing in memory un-encrypted then Silverlight then I think you're in trouble.
The .NET framework does have a SecureString class for exact purpose you outline.
Unfortunately the Silverlight version of the framework does not have this class. Hence even if you were to keep the logical storage of the password encrypted at some point your code would need to decrypt it before using it. At the point there is memory allocated containing the string in unencrypted form.
I don't know much about Forms authentication but if you can map the User principle to a domain user (which you seem to indicate you need) then you will want to use impersonation when running your code on the server.
Alternatively stop using Forms authentication and use Windows integrated authentication where you definitely can use impersonation server-side.
Encryption should never be used for passwords. When you encrypt something then it follows there should be a way to decrypt it. One way hashes should always be used for passwords. md5 and sha1 have been proven to be far too weak for any secuirty system.
Sha256 should be used, and in silverlight this library will take care of it:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256%28VS.95%29.aspx
In fact storing passwords using "encryption" is recognized by the vulnerability family CWE-257. The use of a message digest is the ONLY way to safely store passwords. I didn't just make this up, this is coming from NIST. There are many other vulnerabilities that come up when storing passwords. Here is THE LIST that NIST has put together: