Facebook
Twitter-
Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
To continue sharing your ideas and feedback, please visit features.plesk.com
Question mail_auth_view truncates output
- Thread starter burnley
- Start date
-
- Tags
- ppp-69366 pppm-15106 pps-18214
@burnley , as mentioned by @AYamshanov , this was indeed intentionally done to address a formatting issue with the column width. Our team now registered a new task (PPPM-15106) to make truncation optional. At this point, we cannot provide a workaround or an ETA on when the change will be introduced. You can monitor the change log here.
@AYamshanov and @Sebahat.hadzhi
The intentional change is quite understandable - there is no reason to show the entire hash of a password, which hash is one of the things truncated.
However, it comes to mind that ..... if this change was intentional ....... why is the prefix $2y$12$ visible?
The whole purpose of hashing is increased security and even if all passwords are hashed, a hacker would think "given the prefix, it can be hacked!"
As a bit of food for thought : would it not be better to remove that prefix?
Sure, I am aware that a hacker able to run the mail_auth_view utility should also be able to change passwords .... but still, that prefix is counterintuitive.
More importantly, one could argue that there still is an issue that is not really a bug.
The table width cannot be adjusted, as far as I know.
It would be more practical to have some flexibility and to be able to set the table width.
This is not really related to password hashes, but related to a potential situation in which a long domain name has been used - that should be visible.
In short, could Plesk Team be so kind and think about flexibility with respect to output of mail_auth_view utility and security by obscuring specific data?
Thanks in advance!
ChristophRo
Regular Pleskian
$2y$12$ is the hashing algorithm used, in this case bcrypt.
It's the recommended method, to store the algorithm together with the password this way and I don't see why that would pose any security risk.
"Security by (pseudo) Obscurity" is not a thing! and not doing it this way would only really! hurt down the way in the future.
It also makes absolutely no sense to obscure any information within the mail_auth_view utility. (with truncating I have no problem as it helps with the visibility - at least if there is a switch I can use to see the full length when needed)
It's the recommended method, to store the algorithm together with the password this way and I don't see why that would pose any security risk.
"Security by (pseudo) Obscurity" is not a thing! and not doing it this way would only really! hurt down the way in the future.
It also makes absolutely no sense to obscure any information within the mail_auth_view utility. (with truncating I have no problem as it helps with the visibility - at least if there is a switch I can use to see the full length when needed)
@ChristophRo
This statement
seems logical, but it is not.
The $2y$12$ prefix is integral part of the hash ...... but also an indicator of a not-so-strong hash.
Any person able to see that prefix will be able to conclude that there is a relatively weak hash that can be reverse engineered.
Any person with those abilities is also - very likely - to do the actual reverse engineering.
With the right sofware and servers AND KNOWLEDGE, it should take a couple of hours.
That is the "normal approach", but one should be more worried about the other possible approaches that exist when the hash is generated with PHP.
This statement
I can fully agree with, with the exception of information concerning the (type of) hash.
Visibility is important and flexibility to adjust column width is (more than) desirable.
Kind regards...
This statement
seems logical, but it is not.
The $2y$12$ prefix is integral part of the hash ...... but also an indicator of a not-so-strong hash.
Any person able to see that prefix will be able to conclude that there is a relatively weak hash that can be reverse engineered.
Any person with those abilities is also - very likely - to do the actual reverse engineering.
With the right sofware and servers AND KNOWLEDGE, it should take a couple of hours.
That is the "normal approach", but one should be more worried about the other possible approaches that exist when the hash is generated with PHP.
This statement
I can fully agree with, with the exception of information concerning the (type of) hash.
Visibility is important and flexibility to adjust column width is (more than) desirable.
Kind regards...
ChristophRo
Regular Pleskian
Given the circumstance that your server is compromised and the hacker has gained root access (otherwise they could not use the mail_auth_view utility anyway), what is stopping them from executing
and/or
to see the hashed password of all users and accounts on your system? (including the encryption algorithm)
As for the bcrypt hash itself - it's considered a very safe algorithm and it's also quite slow, thus making it somewhat hard to brute force.
I also don't get what "generated with PHP" has anything to do with security or would pose a problem...
Code:
cat /etc/shadow
Code:
plesk db "select password from accounts"As for the bcrypt hash itself - it's considered a very safe algorithm and it's also quite slow, thus making it somewhat hard to brute force.
I also don't get what "generated with PHP" has anything to do with security or would pose a problem...
@ChristophRo,
First of all, if a server is fully compromised, then a server is compromised - no need to obfuscate passwords (or not) in that specific scenario.
However, when a server is not fully compromised, parts of the server can be accessible and that can be enough to reverse engineer hashes.
In fact, bcrypt is not safe at all - takes 2 hours or less to crack a password hash with the right tools, servers and software.
This simple fact, being the lack of safety, is widely understood and also acknowledged.
Even in PHP, one is advocating and allowing implementation of stronger "hashes".
If you do no grasp the concept of "what PHP has to do with it", then - simply - think of the verify_password function in PHP.
In essence, the verify_password function uses the simple facts that both the prefix and the salt are sufficient to verify the password.
In fact, the whole hash contains the prefix, the salt and the hashed password.
Stated differently, one is simply "safeguarding a password" with the method "I will not tell anybody, I write it down on a sticky note and put that on the PC".
That is not the best method, right?
All of the above is a very very very simple explanation that is really not exhaustive.
Kind regards....
PS1 The prefix $2y$12$ signals hashing with "only" 4096 rounds - this will not scare any attacker. That "cost" of 12 (i.e. 4096 rounds) is also equivalent to the signal that reverse engineering is not impossible within a reasonable time frame.
PS2 Any prefix containing $5$ or $6$ would be a solid signal that it does not make sense to attempt password cracking - if one needs to provide any signal, then it should be a signal of "do not try, do not waste your time" ....... and hence my question (not request!) to obscure the $2y$12$ prefix.
