Dump user's password to try to crack them
-
I would like to dump user's password's hashes to try to run the kind of Johny The Ripper on them.
Could you please, advice the easiest way to do that? Ideally - some command line for that purpose?
-
-
@murgero if I != know specific system insides, it != mean I don't have to do security audit.
-
The mysql database has the hashes.
mysql -uroot -ppassword(sic) . Then, in theboxdatabase you will have theuserstable with the info you need.@girish thanks! And where do I get mysql password for that purpose? What is the IP to connect to?
-
G girish marked this topic as a question on
-
G girish has marked this topic as solved on
-
-
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
