Bug #20295
closed
fe_user passwords are visible in the backend
0%
Description
The fe_user password field of the Typo3 backend is set as <input type="text"> while it should be <input type="password">.
This results in user passwords being disclosed to a site admin and it is a security problem because many users tend to use the same passwords on many different websites. So an fraudulent Typo3 website admin may use this information for bad purposes.
Actually I beleive user passwords should be cyphered by default in any CMS and an administrator should never have access to these. If the password is lost, he always has the possibility to redefine one and thus such behavior is not blocking, but it is obviously much more secure for users. Ask the typo3.fr forum administrators what they think about this : they have been hacked the forum database twice this year.
Also MD5 is not strong enough for cyphering password (can be spoofed with rainbow tables) and a better cypher should be retained.
(issue imported from #M10873)
Files
Updated by Franz Holzinger over 15 years ago
But which encryption method should be used instead of MD5? If someone has a Botnet with one million computers, he will always be able to decypher even much better encrypted passwords.
You can improve MD5 by demanding longer passwords than 12 characters on the registration.
Updated by Marcus Krause over 15 years ago
TYPO3 4.3 will have major improvements in regards to password storing/transferring security:
Asymmetric encryption (RSA) when transferring, salted password hashes when storing.
Updated by Chris topher over 14 years ago
I just checked that:
The FE user passwords are still shown in the info popup in the list module.
Seems like this was forgotten when dealing with #19616. I think we should handle this the same way.
Alban, could you post a patch to core list?
Updated by Lars Houmark over 14 years ago
I have attached a patch (10873.diff) that will hide the password by changing it to a random number of asterisk (*).
This will happen in t3lib_befunc->getProcessedValue and the check is done generic, so that any field that has eval to password will have that replaced, thus this will work for user tables as well.
I am going to post a RFC to the core list within a short time, but please review the patch so we can get this into the very next release.
Updated by Lars Houmark over 14 years ago
And since the described problem in this bug is not the problem I fixed, I decided to create a new bug #22588 and attach the same diff to that one.
This is now also posted to the core list, waiting for review.
The editing of FE users in the backend have been improved in 4.3, so the bug described in this report is no longer, and therefore this report can be marked resolved.
Updated by