Im using the default WSO2 IS ldap store and it was configured to store passwords in plain text, and they indeed were in plain text.
Then I enabled the password hashing in WSO2 IS as described here:
http://xacmlinfo.org/2015/06/10/user-password-hashing-with-wso2-identity-server-wso2is/
It works for new users, but the old users (before the password hashing is enabled) are still with plain text values.
Can I trigger somehow the password hashing for these users?
Related
Currently we are using wso2is v5.8 in our product to authenticate the user from AD/LDAP.
At the time of login, we sending login form data in simple text format and it's working as expected but due to vulnerability we have an issue, we want to post-login form data password field as an encrypted format. how I will achieve that pls help me with that. Thanks In Advance.
In WSO2IS from user store managers, passwords can be encrypted so no need to send encrypted passwords from the Login page or Registration page.
1. Encrypt passwords in primary user-store manager
Go to < IS-HOME >/repository/conf/user-mgt.xml file and then in there uncomment the below line
<Property name="PasswordHashMethod">PLAIN_TEXT</Property>
and for the hashing method, you can use
SHA - Uses SHA digest method. SHA-1, SHA-256
MD5 - Uses MD 5 digest method.
PLAIN_TEXT - Plain text passwords.
2. Encrypt passwords in secondary user-store manager
In the secondary user-store managers there is an option "PasswordHashMethod" available to configure, if it is not configured it will not do any hashing to the user password.
But in there can specify the Password Hashing Algorithm used the hash the password before storing it in the user store.
Possible values:
SHA - Uses SHA digest method. SHA-1, SHA-256
MD5 - Uses MD 5 digest method.
PLAIN_TEXT - Plain text passwords.
Note:
If you just configure it as SHA, it is considered as SHA-1. It is always better to configure an algorithm with a higher bit value as digest bit size would be increased.
I am using wso2-is-5.1.0.When i use UserAdminStub changePasswordByUser webservice it allows me to use the old password as new password.Is this the expected behaviour or is there any config which can be set so that the wso2 throws an error when both new password and old password are same ?Most of the identity Management does not allow old password to be reset as new password.
Although this is not supported OOTB, you can create a new UserOperatoinEventListner to support this feature.
Thanks
Isura
Since WSO2 IS 5.1.0 does not support this OOTB, one workaround for this can be to implement org.wso2.carbon.user.core.listener.UserOperationEventListener [1] class's following methods.
doPreUpdateCredential
doPreUpdateCredentialByAdmin
Here when a user tries to update password or when an admin tries to update the password of a user, these methods get hit before performing the operation. Here we can do a validation and allow/not-allow the operation. The validation can be to maintain a table in the database for storing passwords (hashed) of the users that are previously set.
[1] https://github.com/wso2/carbon-kernel/blob/v4.4.3/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/listener/UserOperationEventListener.java
I have this problem when using SAML SSO authentication. I have successfully set up WSO2IS 5.0.0 Identity server, I also succeeded setting up (at least I hope so) secondary user store. I used JDBCUserStoreManager implementation. I have set this store as DOMAIN. This user store works nice, at least I think it does. Because it is storing user attributes into its tables (USER_ATTRIBUTES) and those attributes are read by WSO2IS administration ...
https://localhost:9443/carbon/userprofile/edit.jsp?username=DOMAIN/demo_jbu&profile=default&fromUserMgt=true
Users are identified as DOMAIN\username so when I want to log in user from this DOMAIN, request goes to my AUTHENTICATOR implementation so I can manage authentication for users from this domain.
What is strange is, that if I use WSO2IS administration pages, I can set and read users's attributes well. And if I use SAML SSO authentication (have already set up service provider & claim mappings) for users from PRIMARY domain, everything goes fine and calling SP gets all attributes - mapped in WSO2IS administration here:
https://localhost:9443/carbon/application/configure-service-provider.jsp
If I use SAML SSO authentication, but I want to log user from my DOMAIN, SP doesn't get anything.
I can override this behavior in DefaultResponseBuilder, I can put into SAMLResponse anything I want, but I don't feel this approach is OK. Can anyone tell me, where to look for an error? What may be wrong? Where should I start looking for problems? I have already tried to debug it, and it seems it (SAML SSO/AUTHENTICATOR) doesn't find any claim for DOMAIN user.
Thank you in advance.
Josef
I think this is bug in Identity Server 5.0.0. When you are using SAML2 SSO, user can login to Identity Server with both username with domain name and username without domain name. Basically
bob and foo.com/bob must both works and returns the bob user's attributes from foo.com user store. However there is issue with IS 5.0.0, if secondary user store user login without domain name, Identity Server does not returns the user attributes. But, please try to login with foo.com/bob , Then it would return the user's attributes.
You can find the public jira. It contains source diff. It must be a simple fix and you even can compile the source and add fix in to the Identity Server.
I'm using WSO2 Identity Server 5.0 for SAML SSO and need to have user passwords expire after n days. I found the following properties in identity-mgt.properties but I can't find any documentation on how to use them. Is this functionality implemented/available?
Authentication.Policy.Check.Password.Expire=false
Authentication.Policy.Password.Expire.Time=0
Thanks
These two properties had been introduced initially to IS planning to support password expiry, but the implementation was never done.
if Authentication.Policy.Check.Password.Expire is set to true, then the when the user updates the password, timestamp of password update is set as a user claim.
But Authentication.Policy.Password.Expire.Time is not logically used anywhere in the code base, and ideally should be removed.
Anyways, you can achieve the same functionality in a different way using password policy authenticators in IS. Hope this helps.
I'm writing a web app in Django that is interfacing with the Read it Later List API (http://readitlaterlist.com/api/docs/). However, all of the API calls require sending the username and password with each request. In order to do this, it seems that I need to store the user's password in plain text in my database. Am I missing something or is that the only approach possible in this case? Is there some way to store an encrypted password in my database, but yet be able to send a decrypted version of it when making the API call? If not, then are there any best practices that I should be following to safe-guard the user's password?
I'm pretty sure that this can't be the only service requiring sending password in plain-text. I'm interested in knowing how developers deal with these sort of services in general. I'm new to web development, so any help or pointers is appreciated.
do your users have to log into your website to use it? if you also are making use of a password authentication scheme, you could piggy back on top of that. Use the login password for your site as a cipherkey in a symmetric key cipher to encrypt the api password. then you need only store a hash of the users password (to your own site) and an encrypted password for the remote api.
Never save password in plain text. You can encrypt and decrypt the password but the problem is that the key you use to do the encryption and decryption will generally be accessible to anyone who has gained access to your server so it's not secure.
An alternative is to ask them to enter their password and save it in an encrypted cookie, or session variable or something else that will expire when they have logged out of your app. This has the drawback of them having to enter their password every time they user your app.