View Encrypted Data permission will allow the user to see the original value of the field both in the UI and via API.
You can use a permission set to add the "View Encrypted Data" permission to a specific user.
If you do add this permission, keep in mind that it is ORG WIDE for that user so you will have to be mindful of FLS for those encrypted fields you do not want them do see.....
One workaround would be to use custom encryption logic and store that data in a text field.
For instance, assuming you're using a web application, when a user registers or login you'd want to take that literal String, execute your logic (using as as secure methods as possible (e.g. bcrypt/PBKDF2/scrypt)) and either store (e.g. on registration) or compare (e.g. on login) that encrypted String.
In other words, particularly when it comes to passwords, you never want to work with the literal string nor would you want something to be easily decryptable lest you want to run the same risk Sony, Adobe, Kickstarter, Blue Ocean, Target and others have. The password data you hold in your database should be totally alien, even to you and your administrators.
Although not the best, someone had a similar question here.
Hope this helps.