social_experiment wrote:Bind wrote:...I would not want a critical insecurity like that anywhere near any of my applications...
Are you refering to the ability of viewing source code here? I do refer to that option but not via the browser.
I am refering to what
you were refering to when you stated,
"... If the source code is available why not use that to create another hash? ..."
The only way that is accomplished would be by using a browser.
social_experiment wrote:Bind wrote:Look for an online md5/SHA1 hash generator to obtain a new hash for the new password you wish to use before changing it in the database.
And finding a generator (online) that generates specific hashes for your system is not an insecurity? It sounds like a much bigger insecurity than scouring through your source code to look for how that administrator password is constructed.
You are talking about 2 completely different things here. 1-Finding the hash method and 2-developing a hash using that method. Neither is insecure.
social_experiment wrote:Even if you do find the administrator password hash in the database, how do you know the construction of the hashed value? Sure you can take a look at the length of the hash but that does not make it a given that the password has just be been 'hashed' with sha1 or something similar. There could be a salt, unique id which might not be apparent by just looking at that password hash.
It very well could be. Absolutely one should look through the source code in replacing the hash doesnt gain admin access, but to replace the hash, it should be direct database access and replacement -
not scripted. I tend to try the easiest thing first instead of slopping through a boatload of source code. I have fixed hundreds of databases where administrators could not gain access in many applications. I have yet to find a password that required $salt. You do bring up an excellent point though. By combining different static user details as $salt+password to generate the value it would
appear to make the system much more secure if any datacenter employees got nosey or anyone got database access locally. But still, if they have that access, they have access to the source code and would know what to look for if they were seriously intent on snagging user accout passwords, so at best, in this instance, its wet paper bag security in my opinion.
social_experiment wrote:Bind wrote:If the system was developed in a decent structure it should only take 5 seconds once you find the the user accounts table
This will also then apply to a cracker, and then using an '
online md5/sha1 hash generator' they can quickly change your admin password. If the attacker can access your files to check the source code for how the password is constructed then having a administrator password to protected the system is moot.
All decent database servers have remote connections/access disabled by default, so a cracker would not be able to get in to the server to begin with unless the applications security was compromised,
How would they know the hash ?
How would they gain access to change it ?
Even PHPmyAdmin is HTTP_AUTH protected so they couldnt get in there TO change it.
What you are doing is simply going in and changing the value.
You do not want this to be in your source code at all - you want to do it manually for security purposes.
Its such a rare occurrance that the need for scripted ease-of-changing does not over-ride the sercurity implications - at least not for administration privilage purposes. For user accounts its fine and should be there, but not for administration.