Actually, technically it doesn't have to be in the database at all. I don't know if anyone has looked carefully at the JavaScript, but it appears the password, unlike everything else, is populated from client side JavaScript. It could be stored in a cookie or HTML5 local store or any number of other ephemeral client side storage tricks. It would be set when you login, from your browser. The server might only store an HMAC.

Not quite true. It could be (and probably is) encrypted in the database.

I haven't seen where it pulls the password from, but in theory it could pull it local session cookie.

Can you elaborate? I don't know any way to take a hashed password and get the plaintext version. When you log into any app i've worked on, we hash the pw you send and match it with the one in the db. This is why you have to get a password reset most of the time, because the company literally does not know your password.

A cryptographic hash is one-directional (among other things).

However, encryption is the the same as hashing, and it can be decrypted. It is possible that they are not hashing your password, but encrypting it, before they put it into the database.

Encrypted, not hashed. As in, encrypted with a key that can be used to then decrypt it later.

That doesn't make sense. Three days after you sign-up (i.e. no cache), if they are sending you your password, it can only be because it's plaintext. Unless they are bruteforcing the hash for your convenience... :-)

They could two-way encrypt which seems safer to me than plain text but some disagree (I'm not sure why).

Only if the keys are well controlled.

If the keys were well controlled, you wouldn't have to worry about plaintext passwords in the DB either. But passwords get leaked all the time. If the key is sitting somewhere locally, when they break in to steal the passwords, they can steal the key too. There's no way the program can reverse the password without having the key pretty easily accessible.