Are passwords stored in memory safe?

You will have the password "in memory" anyway, however briefly. The longer it hangs around, the greater the chances of it being sniffed. But, if someone is in the position to sniff passwords out of your memory to begin with, you're already compromised beyond hope. As such it will make little difference whether you keep it around for longer or not.

This may or may not say anything about the security of the rest of your AJAX/REST infrastructure, perhaps you shouldn't be using plaintext passwords there to begin with. E.g., move to a token system in which the plaintext password is not needed after initial authentication. But that's too broad to say from the snippet we see.

The question is what attack are you trying to prevent?

When trying to think if something's secure or not try to list out the possible attackers, and then see if they can attack it. For example, in this scenario:

• An off-device attacker (network based):

  An in-memory password is safe in all regards.

• An on-device attacker, different user, non-admin

  An in-memory password is safe in all regards, since OS restrictions prevent the attacker from accessing the memory block.

• An on-device attacker, same user, non-admin

  An in-memory password can be leaked if an attacker can gain access to the system under the same user account as your code.

• An on-device attacker, different user, root

  This is the same as above, the password can be leaked.

However, there's an important gotcha here. If an attacker can get access as the same user or as root, you've got FAR bigger problems. For example, they could tamper with your code to send all passwords (when they are entered) to them remotely.

So in practice, the password would be leaked in either case.

There is one major exception though. Imagine you get a segfault in the application. The OS takes a core-dump. If you stored the password in plain text, the password is in that core-dump in plain text. This is a pretty significant problem.

Recommendation

While practically, any attacker who could read a plain text password could do other nasty things, we want to practice defense-in-depth. That means providing multiple speedbumps to attackers. We don't want to make things easy for them.

So I would suggest to not store plain-text passwords in memory. If you need the plain-text password later (for login to remote systems or something) I'd suggest to rearchitect to not (use OAuth2 or anther federated auth system). But if you must, at least encrypt it with a key that's not stored (or at least kept) in memory.

Even better would be to 1-way hash it, just as you would for storage (using bcrypt, scrypt, pbkdf2, etc).

Every point where an attacker might get access to the plain text password is a problem. On the other hand scenarios where this will be attackable, whilst alternatives are not are extremely rare (though I can think of a few).

Either way, what it seems you wish to do is allow the user to log in after registration, possibly whilst waiting for the confirmation mail to be validated? In that case it would be a better idea to store the username and password in server side memory, as it still gives you all the same advantages without the danger of it being found suddenly. And ideally you do not store the password in server side memory, just the username and a flag/timestamp that the password was correct.