Are passwords stored in memory safe?

Question

I tend to store users password in memory for later uses.

var credentials = {};
function register(username,password){
    //when users click sign up
    credentials.username = username;
    creadentials.password = password;
}
function login(){
    //Users can click login at anytime. Or they just don't.
    ajax('/User/login',credentials).then(function(){
        credentials = {};
    });
}

Should I worry about the security task with this approach? If this is a bad idea, how will attackers retrieve the password?

Answer 1

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).

Answer 2

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.