Let’s start with the basics: you’re supposed to hash your passwords. Basic cryptographic algorithms are a long-gone recommendation there: you should be using PBKDF2, bcrypt, or scrypt. That’s the standard that we call good, but there’s more that you should do beyond how they’re written to disk.
Now that you’ve stored them securely, make sure you don’t go Ashley Madison: don’t use passwords as a basis for anything! In fact, you should never read a password hash for any purpose other than to compare it to a hash. It should be absolutely impossible for your webservers to read the password hash. Webservers should only have access to meta information about the password hash: things like the salt and the number of rounds. The actual comparison to check if the password is valid for a user should be a function call that returns true or false. You can implement this as a stored procedure in your database engine or provide a dedicated authentication service. It’s fine if your webserver can insert or update a password, but it should not have the permission to select it.
Which brings about the next part: if you can’t read a password, you certainly shouldn’t have cause to display it, and thus there are so many things wrong here:
@CSISComputers We don’t allow special char. to protect against cross site scripting. Security measures r an impt part of banking. 2/3 ^MA
— CIBC (@cibc) September 23, 2015
Finally for good measure, I give this admonition for anybody creating session tokens for a browser: create these with random values and store these in their own table so they can be cleared out server-side. It should be possible for you as an administrator to terminate some or all logged in sessions without altering anything else. Each session should have its own random cookie. Facebook, for example, provides this functionality very cleanly: