How to decrypt the password that are stored in WSO2 identity Server with Salt and SHA-256 - wso2-identity-server

I want to view the passwords that are stored in the CARBON_DB..UM_USER table.
The passwords are stored encrypted with a salt value column.
I don't want to change the encryption but want to view the password in SQL server.
If it is a One way function, How WSo2 IS able to get it used when we will call Authenticate function and validate the user name password passed in the request is a valid one?
or it would help me, how the WSO2 Is generating the UM_USER_PASSWORD column based on the UM_SALT_VALUE.

This [1] is the code section where it compares the provided password with stored hash. By looking at this logic, you might able to understand how it happens. Check the preparePassword()[2] method to understand how the salted hashing happens.
[1] https://github.com/wso2/carbon-kernel/blob/4.5.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/jdbc/JDBCUserStoreManager.java#L1242
[2] https://github.com/wso2/carbon-kernel/blob/4.5.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/jdbc/JDBCUserStoreManager.java#L2628

The below is the answer how the encryption is working,
//Password+Salt value
String password = "passwordb7nujixCJvoAA7AZkLfe0A==";
MessageDigest dgst = MessageDigest.getInstance("SHA-256");
byte[] byteValue = dgst.digest(password.getBytes());
password = Base64.encode(byteValue);
System.out.println("password::"+password);

Related

How to authenticate with encrypted email as username?

In my Django web-app, I would like the user to authenticate itself with an encrypted email address that would simply be the username. Due to the existing GDPR regulations in my country, I have to encrypt e-mail addresses and by doing it with the help of Python Cryptography and Fernet functions, each string is different after encryption, even if two strings are encrypted with one and the same key. Is it possible to authenticate the user without errors in such a situation? If this is possible, where can I read a little more about it?
EDIT: Maybe I incorrectly specified: Django uses username and password for authentication, if the encrypted email is username, when logging in, the user will enter the email when logging in, i.e. harry#example.com. The database keeps an encrypted version of this email, so when using authenticate(request, username, password), it will look for a user with the username harry#example.com, not the encrypted version. If at this point I would like to decrypt the user's e-mail from the database and compare it with the e-mail that the user entered when logging in, app would probably has to decrypt all e-mails in the database, and then check if and which one is harry#example.com and here, in my opinion, it becomes quite problematic, because I have the impression that it is a not good solution in terms of time and server load. Is there any other way that I will be able to compare the e-mail entered when logging in and the encrypted e-mail in the database?
Here is a good lesson on how to use python cryptography https://www.geeksforgeeks.org/how-to-encrypt-and-decrypt-strings-in-python/
As for GDPR, the user can enter their email but you should encrypt it on the store, then decrypt it when you want to use it. Make sure that your secret is hidden. If someone gets access to your database and your secret, the encryption is as good as if it's not there.
You should not be comparing the encrypted strings, you should decrypt the email and compare it to the email that is currently entered. Comparing hashes should only be done with hashing, not encryption. If you don't want to have access to the user's email, you should consider hashing instead of encrypting.
There's a good read here How do I encrypt and decrypt a string in python?. To know the how-to around what you need. Plus, you described the solution quite well, so take a look at the following packages from the Django community which achieve what you are looking for:
https://github.com/orcasgit/django-fernet-fields/
https://github.com/orcasgit/django-fernet-fields/blob/master/fernet_fields/fields.py#L117 It includes an Encrypted email field
https://github.com/patowc/django-encrypted-field

how to login with encrypted password at wso2is 5.8v

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.

Comparing password encrypted by bcrypt

I have a webpage that encrypts username passwords using bcrypt, these passwords are then stored in a database. I have a c++ program running on QT which needs to authenticate users, in order to do this i'd have to encrypt the user entered password and compare it to the password in the database. Is this the correct way to do it? If so how do i achieve this? The encryption of the user entered password would have to be the same as the one by bcrypt, how do i do this? Thanks in advance.
Actually you don't encrypt passwords, because they may can be decrypted. The right way of doing it, is to hash a password and store the hash value. If a user enters a password you also hash that value and compare it to the saved hash value. This is the right way because a hash function is a one way function (Non-invertible), see here.
The hash method prevents that somebody can decrypt the password. You should take care of a secure hash function like SHA-2 or SHA-3, because some hash functions are no longer secure, see list of broken hash functions.

Can I use a hashed password as the secret for generating a hmac?

I think it would be very comfortable to use the user's password hash as the secret for generating a hmac. Why is OAuth and others using tokens and nonces?
I think of something like this:
Client enters a password in the ui.
The application registers with the webservice using the hash of that password, which is stored on the server.
Form now on that hash hasn't to be transmitted again.
The client can always regenerate the secret by asking the user to enter the password and hashing it. Every message is signed with this hash, the server can look it up by username or guid and check if the sent mac is valid.
A intruder on the server can get that hash, but doesn't know the users real password, anyway he could send valid request with that hash. But this is not likely to happen, the saved hashes could also be hashed again using a nonce. Anyway because the pwd-file will be on a client's server it should be obfuscated using e.g. base64 to avoid the file looking like {"password":"a4bd146hashhashhash"}.
Most of all the real password of the user won't ever be transmitted. The request's will be secured with a timestamp/token against replay (I recognize the purpose of the token here).
Sending a hash would be perfectly applicable for me because the client will never be a simple website with a tag e.g.. The webservice will be used in a ajax-based application and a java desktop application, both of them capable of hashing strings...
What's wrong with that? It's so simple, more RESTFul than anything related to authentication, and i think yet effective. What am I missing?
Greets, kruemel

What is the best way to store password in database when API call requires sending of password in plain text?

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.