I have a list of students that are being added via a form inside the admin area. I'm trying to come up with a password generating solution for each addition that will be both secure and viewable from the admin panel (like below).
I need it to be viewable so that the admin will be able to print out the passwords and hand them out to the parents. But I also want them to be secure in case there's a database breach. Any ideas?
If you want the passwords to be viewable, they can never be really secure in case of a breach.
You may be interested in checking out the following Stack Overflow posts for further reading:
Store passwords in 2 forms:
1) MF5/SHA1 hash for secure validation
2) AES encripted with master password. I.e. in order to view passwords you enter master password and bingo. In case of theft attacker would not get passwords that easy (but can bruteforce).
You can have one XOR the other.
If the passwords are to be secure, you mustn't store them in the database (store some_hash(per_user_salt + password) and compare that on login (as @Daniel Vassallo says)
If the passwords are to be viewable, then you must provide some way to get to the passwords - and if there is one, it can be abused (e.g. passwords stolen). If you decide that you absolutely, positively need to do this, encrypt the passwords in your application before storing them to the database. This won't shield you from all threats, but at least the passwords won't be readable if someone "only" steals your database.
This is one of the few times I would say the software shouldn't be adjusted to the user(s). You're talking a major security risk here.
I would advice making some kind report generator to print passwords that creates (generates / salts and hashes and saves) them on the fly for printing. With this, you could generate the letters to be send as well. Makes the process mostly automated and a person would only have to send them to the printer (if that's even necessary).
Good luck.
You should not do this.
Generate a one-time password that can be used (and could also be stored in clear text) to set a new password via web.
As soon as the passwords are printed, they can be easily accessed by others, so it does not matter at all if you store them encrypted or not.
Others have had the right idea, but were missing an essential step. You should use asymmetric encryption and store a public-key encrypted form of the password + salt.
To verify a password, take the proffered password, combine it with the salt, use the public key to encrypt the combination, and compare it with the stored value.
To retrieve the password, use the private key (kept secure, i.e. on another isolated machine) to decrypt the password + salt and throw away the salt.
Cons: asymmetric encryption can be expensive, computationally, but passwords tend to be short.
You could combine this with other ideas above (i.e. also store a salted hash), and you should pad the password so that the length of the encrypted text doesn't leak the password length.