Dump user's password to try to crack them

[murgero]

I feel like if you don't know how to do this, you probably shouldn't do it.

[potemkin_ai]

@murgero if I != know specific system insides, it != mean I don't have to do security audit.

[potemkin_ai]

@girish thanks! And where do I get mysql password for that purpose? What is the IP to connect to?

[nebulon]

The password is literally password here and the host is localhost. 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.

[potemkin_ai]

mysql -uroot -ppassword box -e "select username,password from users;" > users.list - is a ready to use command, shall anyone be interested.

@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?

[nebulon]

The settings are https://git.cloudron.io/cloudron/box/-/blob/master/src/users.js#L98 so you can search through that file to see how passwords are handled internally.

[potemkin_ai]

Thanks! Code worth thousands words

[potemkin_ai]

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?

[girish]

@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 salt you see above is the per user unique salt. It's a field in the same table. Hope that answers!

[potemkin_ai]

@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...