Plain-text password and "remember me", node.js and js client

Question

I'm trying to understand a little bit more security in my node.js (with passport.js) and client (pure javascript) web application. But I'm very new to the web programming.

I have implemented a LocalStrategy and it's ok. To gain access to some api I have to log in as a normal account, or to log in as admin in some others.

I'm testing it with browser authentication (still don't have a "remember me" feature so each time I have to retype password) and I'm testing it with curl:

curl --cookie-jar jarfile --data "username=admin&password=pass" http://localhost:5000/login
curl --cookie jarfile "http://localhost:5000/api/admin"

Now, following the "expect worse" paradigm, I'd like to be protected a little bit from man-in-the-middle attack so I don't want to send plain-text password: I have to crypt the password in the browser (sha256), send it, and store/compare the hashed password.

1. What I don't understand is the salt thing. What is the more used pattern? Generate in the server and send it to the login page? How to test it with curl? Does it has to be always a different one? The user has to insert it in the login form?
2. What about the "Remember me" thing? I really don't understand this: do I have to store a cookie in the browser with username, encrypted password, and the salt? Why the "remember me" implementations are in server side? Should't it be in the client?

Sorry but I haven't found in the web anything that clearly explain those concepts with node.js and passport.js, pure javascript client and curl test (I really care on testing with curls).

Answer 1

explain those concepts with node.js and passport.js

Those concepts are not dependent on a specific runtime or framework, so it makes sense that materials on the web don't refer to node.js and passport.js

1. ... the salt thing

Salt is a string that makes it harder to crack passwords. You should use a different salt for each user. What I often see is that the use of salts is only relevant to the server. The client sends the password in the clear, and the server hashes it with the salt. Thus it won't affect testing with curl. If an attacker could log in with the salted hash alone (thus not needing to know the original password), it makes the salt and hash less useful.

2. ... the "Remember me" thing

Usually instead of transmitting the credentials for each request, there's a single "session ID" sort of token. The server maintains state to associate session IDs with user records, thus "remembering" that the user is logged in. It's uncommon to store the password in a cookie.

each time I handle a login i have to store a session ID and send it to the client? and the client send it back to me?

That's how a lot of sites do it. I guess there's room for variation though.

the curl --cookie-jar jarfile --data "username=admin&password=pass" http://localhost:5000/login actually store the username and password in a cookie, isn't it?

It sends the username and password to the server, and the server can respond with whatever data it wants to have stored in a cookie. If the server sends back the username and password as a cookie, then yes. If it sends back a session ID instead, then no.