Socket.io and Node.js Chatroom with admin area - node.js

I am making a chat room with socket and node, I want an admin area, so lets say the chat is at localhost:3000. I don't want the admin area to be /admin for obvious security reasons I am very new to socket and node in fact this is the first app I am creating using these technologies..
So what would be the best solution for a secure admin area..? This has to be done quite quickly and the app has no database so I think a login would be out of the question.. or I could have a login with a static username and password? Is this secure..? I am really not too sure.
Regards

Implementing login would be the best option here. If you are not using any database, you can rely on alternate storing mechanism like in-memory storage or file systems storage to save admin credentials. It is up to your requirement whether to use persistent or non-persistent storage meshanism.
You may use npm modules like bcrypt to hash passwords while saving in storage, if you want to implement security.
var bcrypt = require('bcrypt');
bcrypt.genSalt(10, function(err,salt){
bcrypt.hash(myPassword,salt,function(err,hash){//use the hashed value 'hash' here
});
});
This will defend from threats like Rainbow Table Attacks.

Related

What about restrict passwords reception to bcrypt format?

I'm learning about web security, hashing and encryption stuff.
I'm building an authentication feature for an API REST backend app. I had an idea and i wanted to know your opinion.
What if we apply data validations on "clear" password that we are supposed to recieve from the client ?
From a backend perspective, accepting only password data in a bcrypt hash form. The password would have to be hashed by the front app, sended to the backend, hashed again to compare with the password in DB.
Scheme picture :
It could really increase the bruteforce load and time consumption and the clear/real user passwords would never go out from the user RAM.
I think it could be a good idea but i don't have enough knowledges to apply it blindlessly.

Hash passwords in Node API or in Postgre Database

So I'm working on a mobile app that's driven by a node.js API. My question is, for hashing/storing passwords would it be better to hash them in the node API (with Bcrypt) then send this to the Postgres database, or should I send the plaintext password to the database and hash it using the crypt() function that is in pgcrypto.
If you send it to the database in plaintext, that is just one more spot where it can be accidentally logged or leaked, or spotted in transit. Why do that if you don't need to? If node.js has a trustworthy bcrypt API, then use it rather than using pgcrypto's.

Question regarding passport.js' level of security

Just have some general questions about the level of security one can expect when using passport for an App's Authentication;
I am currently in the process of designing my first App using a MongoDB, Express, React and Node.js stack. Without having much prior knowledge about cyber security I have done quite a bit of research about authentication and what type of attacks can occur on my site. I have opted to use a cookie-based authentication system with the passport.js npm package and I have designed my /login route to require that the user's password and username first pass a passport.authenticate('local', ....) middleware setup before a session and cookie are created.
In order to persist the current user in my react app, I have a function which requests the server to provide it with the currently active passport session if there is one - and this seems to work as it will not maintain a login state if the user deletes the session cookie from their browser.
I am a bit skeptical of passport and I'm curious to know how easily it could be breached by someone who has a higher understanding of how it works, so the things I am wondering are several:
Is this type of authentication setup secure?
Are there any additional requirements that one must implement in order for passport to be a
legitimate method of authentication for an App?
Is using passport to authenticate users considered to be bad practice? Would showcasing an app that
authenticates users by using an npm package look bad if I were to showcase this application to a
potential employer?
I can share code if necessary to better illustrate my code setup, although I would prefer not to if at all possible. Any advice would be much appreciated, thanks!
TLDR:
Is passport.js a secure method to authenticate users? Is using passport.js for this bad practice?
Passport.js provides authentication, not security. It is fairly easy to misconfigure by following online tutorials, so take care - the tool is only as good as the hand it is in. To add security to passport, you will need at the very least three additional elements:
Strong state model for the session (or token) that does not leak private fields and uses argon2 for password hashing.
No mistakes on the front-end with CSRF or XSS.
Rate and buffer limitters on Node itself or, even better, on your reverse proxy.

Login details security using salt n hash and a login role in postgresql

I am coding up the security for a website in express.js and postgresql db. Now I have been reading about salting and hashing and I have the code set up with pdkdf2 using the crypto module, but my issue is how I will structure the account table in the db. What If i would create a login role which will have an MD5 encrypted format for the password, which password will be the derived key from the salt n hash "procedure". Would that be an overkill of protection?
There will be a table which will be as follows: UID (the ID from the login role), SALT , HASH.
And also the loginrole.
So on a try for authentication, the code will try to login as that role, first by getting the assosiated UID, generating the salt n hashed password for the password provided and auth on a DB level.
Hope I am making some sense..
var usrSalt = crypto.randomBytes('128').toString('base64');
//text , salt ,iterations , keylen , callback
crypto.pbkdf2(usr, usrSalt, 10000, 512, function (err, derivedKey) {
if (err) { console.log(err); }
else {
usr = derivedKey;
next();
}
});
P.S Would a pgcrypto module be better again in the same scenario, just by removing the code on node.js.
This answer is at a higher level, not the low level of actual code.
"Overkill of protection" is relative to your project. The 10000 iterations will take some amount of time and MD5 will provide some level of encryption. Both might be suitable for your project, and will have to rank as a priority compared to other aspects (speed, features, etc.).
To keep speaking in generalities, some level of good security practices will protect some percentage of your user data, and with a determined attacker some other percentage might "always" be compromised.
The choice for pgcrypto is similar. If it is as sufficient as the code you plan to write (it is defacto more tested than your current code), its handling will be on your DB server. Good to keep it off the Node server? Easy to maintain? Less work? "Better" will be relative to your project.
Salting and hashing passwords is not overkill, it is the absolute minimum you should do if you cannot avoid dealing with passwords entirely.
It's hard to figure out what you mean with the second part, regarding this being used to auth on a DB level. You usually either do application level authentication using your own usernames/passwords, or you create real users in PostgreSQL and let PostgreSQL authenticate them by simply passing their password and username through to PostgreSQL when you create a connection.
There's an intermediate way, which you might be trying to get at. Authenticate the user yourself, then use SET SESSION AUTHORIZATION to have your PostgreSQL database session "become" that user. It's a bit of a specialized approach, and not one I tend to use most of the time. It is mostly used by connection poolers.
See also:
Secure method for storing/retrieving a PGP private key and passphrase?

General user session handling (Nodejs)

I wrote a simple webserver with nodejs and express. I implemented an user authentication with email username and password. Furthermore I have a remember-function which stores the user id and pwd hash into a cookie. Now I would like an extra session that ends when the user will close his browser or click to the logout button.
Which way is the best practice for implementation? Is the session the same like the remember-function with an expire time and in each request I must check the credentials against the database? (I'm not that sure about this)
Technologies that I'm using: nodejs, express, mongodb
This is not a nodejs question only, I would prefer a general explanation for the problem.
Let me get this out of the way first; Storing the password hash into a cookie would allow anyone to login when they have the password hash and that would be disastrous if the password hashes ever got exposed for some reason. Encrypting cookies is just fine, but don't allow the actual hash you store in the database to be used for authentication. Ever.
About re-authentication, Node is a technology that operates on a single thread and is scaled by running more instances over multiple processors and/or machines. Keeping sessions is a good idea to avoid trips to the database, but you have to think about the architecture as well. What happens if you, say, use sessions stored in files (ala PHP) and you need to scale to multiple machines? Nothing good, at least. So you need a central point to keep track of the sessions.
This can be either your database (MongoDB) or something such as Redis, or another centralized mechanism allowing you to check sessions. Either way, you will have to spend time doing the request and retrieving the session values for the client. If you do not have additional values you need to store it makes no sense to create a dedicated session architecture (that needs expiration, and so forth) and just doing the authentication again is the easiest and most logical solution.
Personally I almost never need sessions and just do authentication again.

Resources