I would like to know what type of hash used for active directory passwords and if there is a way to change the type of hash
A user's password hash can be stored in Active Directory using two different proprietory hash algorithms: LM hash and NT hash.
The less secure LM hash is disabled by default by group policy on later Server OS versions but can be reenabled again.
Aside from that the only other way you can affect this is to enable storing passwords with reversible encryption using group policy.
After that is enabled, when you change your password a password filter called RASSFM.DLL is used to store the password using reversible encryption. The key that is used to do this is G$MSRADIUSCHAPKEY, which is stored as a global LSA secret. This key is decrypted using a static key (hardcoded in the DLL). The result of this operation is combined with a 16-byte random value (generated every time someone changes their password) and that key is used to encrypt a Unicode version of the password using the RC4 algorithm.
This information is then saved in the userParameters attribute.
Related
I need to add a sort of salt to a password field in Android. The problem is its with firebaseUI and i do not have direct access to the password EditText. but i do have access to it through styles.
For example in firebaseUI for android we can do the following:
textPassword
that overrides the styles in the password field. I'd like to be able to add a string that would be concatenated to every password here. so essentially i want to do this in xml. if the users entered password is "1234" and my salt is "mysecret_salt" then the final password sent to firebase should be: "mysecret_salt1234". is there anyway to do this through xml since i dont have access to the password EditText directly ?
source:
In password protection, salt is a random string of data used to modify a password hash. Salt can be added to the hash to prevent a collision by uniquely identifying a user's password, even if another user in the system has selected the same password. Salt can also be added to make it more difficult for an attacker to break into a system by using password hash-matching strategies because adding salt to a password hash prevents an attacker from testing known dictionary words across the entire system.
if there is now way to add to the password from client side, is there a way to do it in firebase console ?
Is it possible to take an original hash value, and then decode it back to the original string?
hash('sha256', $login_password_for_login) gets me a hash, as shown below, but I'd like to go from the hash value back to the original string.
With $login_password_for_login = 12345, the hash function gives me this:
5994471abb01112afcc18159f6cc74b4f511b99806da59b3caf5a9c173cacfc5
I'd like to be able to retrieve the original number or string that I had for the login password. How do I reverse the hash and get that original string?
You don't 'decrypt' the hashes because hashing is not encryption.
As for undoing the hash function to get the original string, there is no way to go from hash to original item, as hashing is a one-direction action. You can take an item and get a hash, but you can't take the hash and get the original item.
Make a note that hashes should NOT be confused with encryption; encryption is a different process where you can take an item, encrypt it with some type of key (either preshared or symmetric keys like PGP keys), and then later decrypt it. Hashes do not work that way.
In comments, you indicate that you're trying to save a passcode in the database. The problem is, you don't want someone who can breach the DB to be immediately be able to decrypt passcodes, which is why hashing is so attractive.
The idea, then, is that you would consider using salted hashes, storing only the salt on a per-user basis in the DB as its own record, and then store the salted hash of their original password string in the database.
Then, to verify a password is entered proper, get the salt from the DB, get the user input for a given password, and then using the salt from the DB, get the salted hash for that input. Take that resultant hash and compare it to the salted hash stored in the DB. If they match, you have a validated password; if they don't match, it's invalid.
This way, there's actually no decryption of any passwords readily doable, which means in a data breach situation of your site the passwords are not easily able to be retrieved. (This doesn't rule out someone breaching your database, copying down the data, and trying to brute-force the passwords, but depending on what you enforce for password complexity and the effort a hacker wants to actually go through to get credentials, this is less likely to happen)
I'd write an example of this in a language I understand, but as you don't define what language you're working with, it's not going to be possible for me to write a useful example for you here.
That said, if you're working with PHP, you may find this document on crackstation.net about doing secure salted password hashing properly; there's already PHP implementations to do this proper so you wouldn't have to write your own code, supposedly.
Hashes cannot be decrypted, as they are not encryption.
Although the output of a hash function often looks similar to that of an encryption function, hashing is actually an extremely lossy form of data compression. When I say "extremely lossy", I mean "all of the original data is destroyed in order to get a fixed length." Since none of your original data remains, you cannot decrypt a hash.
That being said, hashes can be used to emulate encryption. What you do is that, when a person registers, you make a tuple containing the hashes of their username and password. Then, when somebody tries to login, you compare the hashes like this*:
import hashlib
from login_info import logins # This is an array containing the tuples.
def hasher(string: str) -> bytes:
stringer = bytes(string)
return hashlib.sha256(stringer).hexdigest()
def login(username: str, password: str) -> int: # Returns 0 if login correct, else 1.
user = hasher(username)
pass = hasher(password)
for i in range(len(logins)):
if logins[i][0] == user:
if logins[i][1] == pass:
return 0
else:
return 1
else:
return 1
* Nota Bene: I am using Python 3 for the example, as my PHP and Javascript are a little out of practice.
EDIT: On second thought, it is actually possible to (somewhat) decrypt a hash. Basically, you take the hash and then try every entry in the corresponding section of the hash table to see if it's right. This is why you should always salt password hashes.
The CredentialRepresentation used in the Keycloak 'reset-password' REST API contains fields for hashing algorithm, hashed password, hashing iterations etc.
This implicates that I can pass through a hashed password and all its hashing specifications, instead of passing the plain-text password to the service. This is exactly what I'd like to do, because passing a plain-text password doesn't feel right.
When I try to call the service without the plain-text value however, I get a 400 error with the error message that the plain-text value is missing. Is there any way to pass just the hashed password?
Passing in a plaintext password (via HTTPS of course) allows keycloak to hash it using the hash algorithm policy of the realm.
If you want to pass in the hashed password value, iterations and algorithm then you also need to provide the hashing SPI that implements PasswordHashProviderFactory and PasswordHashProvider. And I don't think this is available via the reset-password API, but would work with the Update User API (I haven't tested this).
Rather than specifying a new password manually a better security practice is to use the PUT /admin/realms/{realm}/users/{id}/execute-actions-email admin call with "UPDATE_PASSWORD" as the required action. This causes Keycloak to send an email to the user that gives a link to set a new password directly.
I have a rest api which talks to Postgres, right now in the properties file of the api we are hardcoding the DB password.
so we thought when a user role is created in postgres we can use Md5 hash value(or any other encrypted value which should be decrypted by postgres) for the password...and we can use that value(hased value) in api property file instead of hardcoded one.
My question is can we use that Md5 hash value in api dev property file and when the password is sent over network and tries to connect to postgres Will it (postgres) decrypt to actual password and allows the user to connect to DB without authentication failed?????
TL;DR: you can't store the hashed password in a properties file and use it to authenticate unless the client application can recognise that it's pre-hashed and avoid the second hashing pass.
If the client library does recognise pre-hashed passwords (libpq doesn't), the hashed password can be used as a proxy for the real password. You don't need to know the real password if you know the hash. this means it's also no more secure to store the hashed password in the properties file than it is to store the original password.
The password is salted and hashed again before being sent on the wire so you can't sniff what you see on the wire and use that to authenticate.
Looking at the source code, sendAuthRequest in src/backend/libpq/auth.c:
/* Add the salt for encrypted passwords. */
if (areq == AUTH_REQ_MD5)
pq_sendbytes(&buf, port->md5Salt, 4);
port is struct Port in src/include/libpq/libpq-be.h, which has:
char md5Salt[4]; /* Password salt */
This is set by ConnCreate in src/backend/postmaster/postmaster.c:
/*
* Precompute password salt values to use for this connection. It's
* slightly annoying to do this long in advance of knowing whether we'll
* need 'em or not, but we must do the random() calls before we fork, not
* after. Else the postmaster's random sequence won't get advanced, and
* all backends would end up using the same salt...
*/
RandomSalt(port->md5Salt);
Now, passwords are verified in md5_crypt_verify in src/backend/libpq/crypt.c. There we see that passwords already stored as md5 are hashed again with the session salt:
if (isMD5(shadow_pass))
{
/* stored password already encrypted, only do salt */
if (!pg_md5_encrypt(shadow_pass + strlen("md5"),
port->md5Salt,
sizeof(port->md5Salt), crypt_pwd))
{
pfree(crypt_pwd);
return STATUS_ERROR;
}
}
Thus the hashed password sent on the wire is protected against replay attacks by the session salt.
Whether the client app can recognise a pre-hashed password and the format it expects them to be in depends on the client library.
According to pg_password_sendauth in src/interfaces/libpq/fe-auth.c the libpq front-end doesn't seem to check for pre-hashed password input. Other clients may vary.
Just to be clear - md5 hashing is not encryption.
19.3.2. Password authentication
The password-based authentication methods are md5 and password. These
methods operate similarly except for the way that the password is sent
across the connection, namely MD5-hashed and clear-text respectively.
If you are at all concerned about password "sniffing" attacks then md5
is preferred. Plain password should always be avoided if possible.
However, md5 cannot be used with the db_user_namespace feature. If the
connection is protected by SSL encryption then password can be used
safely (though SSL certificate authentication might be a better choice
if one is depending on using SSL).
PostgreSQL database passwords are separate from operating system user
passwords. The password for each database user is stored in the
pg_authid system catalog. Passwords can be managed with the SQL
commands CREATE USER and ALTER USER, e.g., CREATE USER foo WITH
PASSWORD 'secret'. If no password has been set up for a user, the
stored password is null and password authentication will always fail
for that user.
If you configure your Postgres client authentication file (pg_hba.conf) for md5 password-based authentication, you don't need to explicitly use md5() function to keep database password in your property file.
For encrypting purposes - you can configure database connection to work over SSL. Please check Secure TCP/IP Connections with SSL.
I am using the PKCS#5 standard to generate a key using a random and unique salt and the user`s password in input. Consider this key as the "encryption" key.
The "encryption" key is used to encrypt a random AES key. Each users have an AES key associated to their profile.
So, a user`s profile will contains this informations:
--> password hash for authentication purpose.
--> salt used in the PKCS#5 algo. (From the PKCS#5 V2.0 documentation, we know that this information needs no protection).
--> the encrypted AES key generated randomly and encrypted with the "encryption" key generated by the PKCS#5 algo with the salt and the user`s password
I was asking myself if it is dangerous to be in possession of the password`s hash, the salt and the encrypted AES key IN THE SAME TIME. I am 99.9% sure that this is not a problem, but can it facilitates the work of an attacker being in possession of all those details?
The password hash also needs to use a salt, otherwise dictionary attacks are possible and two users who happen to pick the same password will have the same hashed password stored in the DB.
I would suggest this: Just use PKCS#5 twice; once to generate the hashed password (which you store in the clear), and once to generate the encryption key (which you do not).
Make sure the salts are large, random, and independent, and then there will be no detectable relationship between the password hash and the encryption key. That is what the salt is for, after all.
[update, to elaborate a bit]
Pick two salts s1 and s2. Make sure each is at least 64 bits, random, and independent.
Use the password + s1 as input to a PKCS#5 HMAC on the empty string. This is the "hashed password".
Use the password + s2 as input to a PKCS#5 encryption scheme to encrypt the actual data.
Store the hashed password, s1, and s2 in the clear in the database. Done.