I just saw how to retrieve password from within hook_user_presave(); Not to put a too fine point on it, I believe the use case presented by the OP does not make sense, and the only use case I can see for this question is to set up a phishing site to collect clear text passwords that can then be used too gain access to the same user's account on other social media websites (it is well known that while strongly discouraged, users still reuse account names and passwords on other sites).
The use case presented by the OP is the following:
the client has an external database which it wants to be totally synced with the drupal database, this is the use case.
Having a client that (apperently) wants to have clear text user passwords exported to an external database hardly constitues a use case. We're not even told why this client has his mind set on compromising the user's passwords. Further: This use case is obviously not valid since it misrepresents facts (a less polite person than me would call it a "lie"). If the client want the external database "totally synced with the drupal database", the OP must mirror the hashed password since that is what is retained in the Drupal database, not the clear text one, which Drupal - following good security paractices - do not retain anywhere. Misrepresenting a simple fact about how the Drupal database stores passwords is one the things that makes me seriously doubt the motives of the OP.
While we obviously cannot stop anyone from reading the source code and find out how to do this, I think that Drupal SE should not assist people who request information that compromise the security of their users in locating that information. In other words, I believe that such questions should be closed or deleted.
In other words I want "Questions that request information that compromise security." added to the off-topic list on: https://drupal.stackexchange.com/help/on-topic.