@nebulon Thank you! Would you mind helping with selecting proper resulting encryption, please?

It'something at that page: https://hashcat.net/wiki/doku.php?id=example_hashes and I though it shall be 7300, but it isn't...

P.S. Yeah, forcing some password complexity would be nice!

@nebulon , @girish , (or anyone else, actually) I offload the task from my radars for now, but as soon as you want me to run a brute-force attack of the algorithms you've chosen using modern GPU HW, please, let me know the function from hashcat to run.

For my or any other reference, here are the steps to do:

mysql -uroot -ppassword box -e "select username,password,salt from users;" > users.list # note salt field - it's a must

Use hashcat -m $mode $password:$salt then to try if it will be accepted.
$mode to be taken from example hashes table above, better also verify if with hashcat -m $mode --example-hash - the later will show the hash structure expected by hashcat.

Once appropriate mode found (hashcat starts checking the hashes) - this could be offloaded to GPU for a much faster checks and verification against various dictionaries, etc.

I had to do some other password recovery task now and I was unpleasantly surprised with the speed of the brute force efficiency (with john just on modern CPU).

Shall my time permit, I will return here some time in the future; otherwise would be glad to pick up this task once Cloudron's resulting hash will be matched with hashcat's one (or a new mode created).

Length > Complexity. Always.

Yeah, that helps for the password to appear on monitors as a 3M sticks

Edit: does Cloudron have some internal logic like complexity rules apart from the "Password must be at least 8 and at most 265 characters" check of the ui?

https://git.cloudron.io/platform/box/-/blob/master/src/users.js#L183 so we only have the length check. Some way for an admin to specify length and complexity would indeed be quite nice, but it would have to be a bit flexible, since we have seen various different requirements from users, depending on the environment where Cloudron operates in.

It'something at that page: https://hashcat.net/wiki/doku.php?id=example_hashes and I though it shall be 7300, but it isn't...

P.S. Yeah, forcing some password complexity would be nice!

in case others are coming back to this discussion later, gitlab also offers permalinks to code files and lines, so that will always work: https://git.cloudron.io/platform/box/-/blob/e536c94028b3ce56f468011af8ca656abb78b37f/src/users.js#L800 (only exception would be if this commit somehow gets completely removed from the repo).

The database is not exposed anywhere so setting a password as such does not add any extra security, which is why it is password to make that clear and avoid obfuscation.

You could switch to https://mariadb.com/kb/en/authentication-plugin-unix-socket/ to get rid of the password completely. this would also strengthen security further by limiting which local users have access.

Edit: does Cloudron have some internal logic like complexity rules apart from the "Password must be at least 8 and at most 265 characters" check of the ui?

https://hashcat.net/wiki/doku.php?id=example_hashes

My idea was that it's IPMI2 RAKP HMAC-SHA1 (7300 mode) - but hashcat refuses to agree with me on that

so this is not possible anymore

That's exactly what I would like to check
You know - people are always the weakest part of the chain...

Am I right that salt is a random piece of bytes that is stored somewhere (if so - where?) and password - is user's password?

Passwords are stored in databases as a one way hash i.e you can only verify if the password is correct but cannot obtain the original password. In very naive terms, if the password (in numbers) is 10+32, imagine storing just 42 in the database. You don't know if 42 came from 40+2 or 50-8 and so on. With this approach, you don't the original math but it's always possible to verify given raw password if the password is correct.

Turns out it's possible to pre-compute this "42" offline. Basically, you take millions of raw passwords and hash them . Then, you can just compare against a leaked database very quickly (it's just a string compare). This is called a rainbow table. To prevent this, you create a "salt". Think of salt as a random number thrown into the hash computation. Say 10 is our salt, we would store 52. Now, an attacker has to create a table for <rawpassword>+<hash>. We are talking very very large numbers here, so this is not possible anymore.

Initially, people started with a single salt for the whole application. These days, you have a unique salt per user. The salt you see above is the per user unique salt. It's a field in the same table. Hope that answers!

pbkdf2Async(password, salt, CRYPTO_ITERATIONS, CRYPTO_KEY_LENGTH, CRYPTO_DIGEST)

Am I right that salt is a random piece of bytes that is stored somewhere (if so - where?) and password - is user's password?

@nebulon , @girish , I know it might sound silly, but you would just save me quite some time - and what's the encryption standard in use?