Support ⇒ Explain Please :: Archives ⇒ Can I obtain a user's password on my site? :: Archived ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexExplain Please

Archived ⇒ Can I obtain a user's password on my site?


This may be a dumb question, but I need to know how to obtain a user's password on one of my sites. I am the admin and I see that on the Members screen I can change their password, but I want to see what it is currently. I checked the users table in the database to see the password hash, but I have no idea how to or if I can decode it.

TIA! Smile

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Apache/1.3.34 (Unix)/MySql 5.0.27-standard-log/PHP 5.1.6/DF 9.1.2.1


It shouldn't be OK for admins to see users password, as they might use it elsewhere too.
Just let the member to use Password recovery feature to have a new password.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
-


chris5000 wrote
I checked the users table in the database to see the password hash, but I have no idea how to or if I can decode it.


It can't (practically) be decoded. The whole point of a cryptographic hashe is that it is not, in fact, reversable. [You could attempt to search for the password using a cracking tool, but really what this does is hash common (using a dictionary) or all possible (OMG slow!) combinations, and comparing them to the original hash. It's a brute-force attack, and very, very slow.]

Having the user use the password recovery would be the best way. If the user's e-mail needs to be changed to accomplish that (because they moved or lost access to the e-mail account), editing the user table to fix that is accomplishable.

It is pitch black. You are likely to be eaten by a grue.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu 12.04, Atom D525/Apache 2.2.22/MySQL 5.5.38/PHP 5.3.10/Dragonfly 9.4.0.0 CVS


Not a security issue, topic moved.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.6 / PHP 5.6 / DCVS


Thanks for the info guys. I see your points.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Apache/1.3.34 (Unix)/MySql 5.0.27-standard-log/PHP 5.1.6/DF 9.1.2.1


darkgrue wrote
chris5000 wrote
I checked the users table in the database to see the password hash, but I have no idea how to or if I can decode it.


It can't (practically) be decoded. The whole point of a cryptographic hashe is that it is not, in fact, reversable. [You could attempt to search for the password using a cracking tool, but really what this does is hash common (using a dictionary) or all possible (OMG slow!) combinations, and comparing them to the original hash. It's a brute-force attack, and very, very slow.]

Having the user use the password recovery would be the best way. If the user's e-mail needs to be changed to accomplish that (because they moved or lost access to the e-mail account), editing the user table to fix that is accomplishable.


The important factors to note are MD5 is used nowadays strictly as an obscurer. It's simply better than storing passwords plain-text. It is also reasonably good at an authentication since it is a hash of all characters in the file. So changing even one character 'should' render a new MD5 value.

Since it's a one way hash, tables can be created of 'all' characters combinations in MD5 format. But this is functionally impossible unless your a spook with canyons of storage space. And I do mean canyons...maybe bottomless pit Smile

Having said this, most folks can easily table up to 8 characters without breaking the bank for storage. I'm still talking terabytes of data here. So 'good' password strength will reduce the chance that someone can simply 'look up' your MD5 hash to determine the password and may actually have to brute force it. This process is intensive, but every day it becomes less intensive.

MD5 should never be considered secure. Good password policies; like changing passwords regularly and using long and complex passwords, will reduce your risk to very low.

For an example, the password 'password' is posted in full MD5 on this site as part of the instructions for recovering an admin password. Obviously you'd never want to use it permanently Wink

So the point is since it's a one way hash, creating MD5's is simple, reversing MD5's is not.

J.
j e r u v y a t y a h o o d o t c o m

Need help? Look here: www.dragonflycms.org/W...d=112.html
Need to chat? Look for me on irc.freenode.net

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu7.10/Debian3.1 - 2.2.3/1.3.37 - 5.0.38/4.0.27 - 5.2.1/4.4.7 - CVS/9.1.2}


Jeruvy wrote
The important factors to note are MD5 is used nowadays strictly as an obscurer. It's simply better than storing passwords plain-text. It is also reasonably good at an authentication since it is a hash of all characters in the file. So changing even one character 'should' render a new MD5 value.


Yup, all characteristics of a cryptographic hash, of which MD5 is one. Once thought to be extremely secure, it's been downgraded because of flaws. Although SHA-1, which is nomally positioned as the replacement for the aging MD5, isn't without its own problems.

Such is cyptography - it's not a matter of perfect, it's a matter of when. Analysis gets better, and sometimes (such as in the case of DES), you just get mowed under by Moore's Law.

Jeruvy wrote
Since it's a one way hash, tables can be created of 'all' characters combinations in MD5 format. But this is functionally impossible unless your a spook with canyons of storage space. And I do mean canyons...maybe bottomless pit Smile


The classical dictionary attack. A good example of technology/economics overwhelming the technique. It used to be infeasible to pre-calculate the hashes because it was too costly computationally, and completely infesible to store. Then it was just too costly to store. Now it's neither.

I remember correctly, the back-of-the-envelope calculations for all possible alpha-numeric passwordsactually without using salt values, you could store the MD5 hash values in a database that would easily sit on a (large) removable USB drive. Most operating systems don't use unsalted passwords though, and salting and stretching can once again put the target well out there, but with data densities growing by leaps and bounds, it won't be long again before it's back on the desktop. And let's face it, governments have resources that don't know the meaning of the word "impractical". Impractical =! impossible.

Dragonfly, as most CMS and web systems, uses a simple unsalted hash. Which might appear to be a source of concern - and it does get brought up from time to time:

"Why doesn't Dragonfly use <some different hash algorithm>?"

"Why aren't the passwords salted/stretched/more secure?"

"The admin can see all the password hashes, isn't that bad? Something must be done!"

MD5 is already implemented and supported. It's simple, it's well-understood, and it's also what PHP-Nuke used. It's also what currently works. Any change to the system, no matter how small, would require all the users to re-do all their passwords. There's no way to "upgrade" a hash to a new hash system - the only way to do that is to keep the old hash (and some value indicating under what mechanism it was created), and then have the user re-enter their password after logging in so that it can be re-hashed (implementing that is actually very complicated, and actually sets up for a situation where security is actually weaker for it, since you have to carry around a legacy system nearly indefinitely). There's no real reason to do this, since the risk value isn't very high for people cracking CMS password tables. The database holding the hash values isn't externally viewable.

Are you really concerned that your database administrators are looking at your Dragonfly password tables and running password cracks against them to do... what? Consider, if you really feel the scenario where your database tables containing password hashes are being extracted and cracked - you have a much more serious problem then considering the state of cryptographic technology and implementation...

MD5 isn't perfect, but it's good enough. Dragonfly just doesn't have a threat profile that justifies more rigorous authentication algorithms or schemes. And that's just fine.

Jeruvy wrote
MD5 should never be considered secure. Good password policies; like changing passwords regularly and using long and complex passwords, will reduce your risk to very low.


Agreed! Big grin

No security mechanism of any kind should be considered secure. It implies finality. Security must be evaluated within the context of the environment and weighed carefully based on risk acceptance and the value of what you're protecting.

It is pitch black. You are likely to be eaten by a grue.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu 12.04, Atom D525/Apache 2.2.22/MySQL 5.5.38/PHP 5.3.10/Dragonfly 9.4.0.0 CVS


Following-up to myself, this article on Dan's Data is of interest. Apparently, the concept of (effectively) distributed password hash searching is now common. Using, of all things, Google.

Which means that unsalted passwords are much mor vulnerable than in the past. Salted passwords are still better, for reasons already mentioned - you have to search all the possible salt values.

All this means is you don't give out your /etc/shadow file, and you don't give out your database tables with the hashes in them. And, you probably shouldn't re-use passwords online for different accounts.

It is pitch black. You are likely to be eaten by a grue.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Ubuntu 12.04, Atom D525/Apache 2.2.22/MySQL 5.5.38/PHP 5.3.10/Dragonfly 9.4.0.0 CVS

All times are UTC