I misunderstood; I thought he had a master password for the entire site in addition to each user's master.
I wondered why you were talking about XSS, but it makes more sense now. If the user's password/hash is stored in state then XSS could potentially recover it for an attacker.
In the case of per-user master passwords, they should not be stored in the database and the hash shouldn't either so it sounds like he got that right. The password/hash can be kept in state for the user's session. I don't know how you mean that he's storing it in the script. Do you mean it's put into the dynamically generated homepage of the user? If so, it's being sent to the user in the clear and would be vulnerable to XSS attacks (if any exist on the site).
Rather than pass it back to the user in plaintext, the site could encrypt it with a per-session key and hand it back to the user that way. The server could generate a new key for each session and use it to encrypt/decrypt the user's password hash during that session without ever storing it in the database. This limits the amount of time that the server ever has the hash accessible to itself and would be especially helpful for inactive sessions. XSS would not work because the user would only have the encrypted hash at any given time and server-side attacks would be limited because the server would only know how to decrypt the encrypted hash and would only have a few decrypted in memory at any given time.
Just to clarify, I'm assuming that he hashes the password with MD5, SHA, or a construction like PBKDF2. That hash would be used as the key to encrypt/decrypt the user's information in the database. Call this value 'hash(password)'. Your friend currently stores the plaintext password in a script for the user's home page, but I'm not clear on how exactly he is doing that. I'm suggesting that he generate a session key and encrypt the hash and pass that back to the user, call it 'encrypt(hash(password))'.
Does this make sense?
BS in IT, CISSP, MS in IS Management (in progress)