Open ilario opened 3 years ago
Just for curiosity of knowing how robust is this system, I took the hash from a comment from @spiccinini https://github.com/libremesh/lime-packages/issues/855#issue-825080302 and submitted to https://www.onlinehashcrack.com
That online service was able to retrieve the password (which actually was quite solid, fulfilling all the FBW criteria (has numbers and letters and is 12 characters long)) but was present in their dictionary.
Hi Ilario, please try using the sha configs using the same password, my guess is that that online method will also crack it as it is in the dictionary. Any hashing function with a password that is in the dictionary will be cracked.
One thing that we can do to rise the barrier against the online services is to add an explicit salting to the password, like, prepending libremesh. This way a special dictionary has to be crafted. Most of these services does not allow to provide a dictionary
Hi Ilario, please try using the sha configs using the same password, my guess is that that online method will also crack it as it is in the dictionary. Any hashing function with a password that is in the dictionary will be cracked.
Yes, for sure. But a stronger hash would make everything more expensive (ok, people using that online service would maybe not notice the difference, but if one tries to crack on its own machine, the difference should be big).
One thing that we can do to rise the barrier against the online services is to add an explicit salting to the password, like, prepending libremesh. This way a special dictionary has to be crafted. Most of these services does not allow to provide a dictionary
Nice idea! But this would make super-complicated for people to connect to the routers via SSH, as the password is not the one they expect.
Other easy mitigation strategies I can think of are:
* stress a lot in the documentation that the hash should not be made public;
For example we could write that here: https://github.com/libremesh/lime-packages/blob/6642f373908d67c9cfc9d8f360843e9c528a8b94/packages/lime-docs/files/www/docs/lime-example.txt#L23
* filter out the root_password_secret in lime-report: https://github.com/libremesh/lime-packages/blob/4b20935a62b2425530c9affecae0a3acb302a297/packages/lime-report/files/lime-report.sh#L13
This still has to be done.
This is an already known issue, but I think it deserves a placeholder to remember that it exists and continue thinking in a solution.
FirstBootWizard exposes the md5crypt hash of the router root password via the router web server: the md5crypt hash of the password set via FBW is stored in lime-community which is exposed via http here.
In some cases, when the router receives a public IP or when port redirection exposes http/https to the internet, this information is available to the internet. See related issue: https://github.com/libremesh/lime-packages/issues/280
The requirements that FBW imposes to the user when setting a password are strict (see here), but a poor choice is still possible.
A possibility to use a stronger hashing algorithm is documented here: https://github.com/libremesh/lime-packages/blob/2b7226a8d249553e5e7fe3ab8e49dce2566bd318/packages/lime-docs/files/www/docs/lime-example.txt#L22-L23
I don't know what could be a better alternative than using the web server. Using SSH would solve automatically #848 but would have the problem that a malicious remote node can receive the typed password directly (for more explanation check out the answers on this page).