Dump user's password to try to crack them
-
-
Thanks! Code worth thousands words
-
Apologies, one more question:
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?
-
Apologies, one more question:
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?
@potemkin_ai said in Dump user's password to try to crack them:
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
saltyou see above is the per user unique salt. It's a field in the same table. Hope that answers! -
@girish , thank you! Yeah, I'm aware about the theory, I was wondering how it's done on Cloudron.
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... -
@girish , I know, it's been a while, but I've got my hands on server with a GPU, so I wanted to run a brute force on the hashes I've got - could you please, help me to identify which of the algorithms are you using in Cloudron?
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 -
An interesting discussion and it confirms my expectation that Cloudron is following modern and good security practices.
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?
-
The code link has changed I guess, so here we are now https://git.cloudron.io/platform/box/-/blob/master/src/users.js#L800
@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!
-
@potemkin_ai said in Dump user's password to try to crack them:
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
saltyou see above is the per user unique salt. It's a field in the same table. Hope that answers! -
An interesting discussion and it confirms my expectation that Cloudron is following modern and good security practices.
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?
@fbartels said in Dump user's password to try to crack them:
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.
-
Length > Complexity. Always.
Both is better.
https://bitwarden.com/blog/how-long-should-my-password-be/
https://pages.nist.gov/800-63-3/sp800-63b.html#appA -
@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!
@potemkin_ai said in Dump user's password to try to crack them:
@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 mustUse
hashcat -m $mode $password:$saltthen to try if it will be accepted.
$mode to be taken from example hashes table above, better also verify if withhashcat -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
johnjust 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
This post is deleted!
