Can't decrypt an password that I need to decrypt.

[ghost]

What behaviour is observed?

So I have an AuthMe password, encrypted in my auths.db. I try to decrypt a password out of this string:

$SHA$d916d124f19a659c$809140c2fc05e72fde5d0d57973e85a1f800b3eda024c9ae7d5ae0fbd23584d0:127.0.0.1:1683666307921

What does this mean? How to I decrypt it?

Expected behaviour

I expected it to be normal sha256.

To Reproduce

1. go to your auths.db
2. try to decrypt the sha256.

Plugin list

Authme, EssentialsX.

Server Implementation

Standalone server (no proxy)

Database Implementation

SQLite

AuthMe Version

5.6

Error log (if applicable)

No response

Configuration

Default config.

[krusic22]

But why tho?

[igs7]

I decrypted it for you, it's 12345678

[ghost]

How did you decrypt it?

[igs7]

It's secret

[ghost]

not really. I own the server, I just need to know how to decrypt.

[mja00]

Take a string, encrypt it with sha256. Did it match the hash in the DB? No? Try again. :)

[ghost]

AuthMe uses a different hash/salt method I think, and I don't know it

[ghost]

12345678

Just referenced it, its not

[games647]

@Cerealistic What do you want to achieve? Do you want to verify the password input with the hash for example for a website integration? Then we are likely looking at decoding/deserializing the structure. Plain hashing functions are unsafe (re: rainbow tables) that's why there a salt added. The salt is included in the output. See the first characters between the dollar sign.

https://github.com/AuthMe/AuthMeReloaded/blob/9fd532d798850de56d6455df2002547876790ac2/samples/website_integration/Sha256.php#L22

This can then be used to generate the same hash and thereby verify the input is equal to the value in the database.

However, if you really meant decrypting (i.e. getting the original input from the hash), this is intentionally difficult by design. Password hashing is a standard practice where the hashing functions are one-way (simplified). You should not being able to see the original input (simplified). If your use case is that a user forgets his/her password, then you should override the old hash. For example: by generating temporarily, random, one-time only password or letting them register again using a new password.

[ghost]

Okay, I will change their password. But how would AuthMe know the hash's correlation to the password if its one-way?

[games647]

If the input is the same, it will generate the same output. The salt is added to the input to make it more unique. Rainbow tables are an attack methodology that uses pre-generated input->output values. By adding random salt values to the input, this attack can be prevented.

[ghost]

... How do I find the salt?

[games647]

My earlier post

@Cerealistic What do you want to achieve? [...] The salt is included in the output. See the first characters between the dollar sign.

https://github.com/AuthMe/AuthMeReloaded/blob/9fd532d798850de56d6455df2002547876790ac2/samples/website_integration/Sha256.php#L22

[...]

BTW: . means string concatenation, so it would be something like this in Pseudo-Code

sha256(concat(sha256(password_input), salt))

[ghost]

I thought "." means multiplication... Anyways closing.

[KhalidPlus]

Blud the password is 10510, dm me at discord (el_spreen) for more info

[krusic22]

I assume you just used hashcat?

[KhalidPlus]

Not exactly, i used python and thanks to the source code i managed to get it. More info at discord: el_spreen