I am currently creating a small chat application on node.js using mongojs, I have a mongo collection of users with a username, password and name fields. The application uses socket.io to send the data real time and then authenticating the user and letting him use the application if the auth is correct.
However, I don't want to send the password on plain text, is there any way of encrypting the password on the client side? Or any better way to do this? I have thinking of using this on a separate page, but I need to do this on Single page.
Here is my client side code:
function loginUser(){
console.log("Login User");
username = $('#login-username').val();
password = $('#login-password').val();
//VALIDATIONS
socket.emit('auth-user', {"username": username, "password": password});
return false;
}
I would strongly recommend against client-side encryption of your passwords.
If you are hashing before the password is sent, then you will have to store the hash of their password as is (or you could hash it again, which is equally useless). But unless you set up a public/private key system to decrypt them server-side, then RE-hash them with a separate hashing algorithm, then you will have absolutely zero added benefit.
I do not know of any major sites that encrypt client side, because the accepted norm is to use HTTPS, since it allows ALL of your outgoing data to be encrypted, by being sent on top of SSL/TCP protocol.
It's important to note that socket.io is not insecure, as you seem to be assuming it is; it follows basic internet protocol, and will be equally as safe as any other site's login that isn't using https. Just something to consider.
Hmm... Very good question. I have never used socket.io with authentications before.
But it seems like passport, passport for socket.io, is the Socket IO's preferred way of handling authentication based on their wiki. I wasn't able to find anything about whether passport is encrypting the data, but it is at least using the POST call.
At the end of the
Related
I have an Electron Application that needs to connect to an external PouchDB / CouchDB and a FTP-Server to retrieve some data. So in my Code I use
remoteDB = new PouchDB('http://my-Couch-User:my-Couch-Password#123.456.789.225:5984/myDB');
ftp.connect({host: ServerIPAddress), user: 'my-FTP-user', password: 'my-FTP-Password'});
I'm not working with highly confidential data, but having my passwords for external servers disclosed in such an easy readable form gives me the goosebumps.
Does anybody have an Idea how to at least hide them a little bit? (I know there is no way of really securing them under JavaScript)
Consider storing the confidential data in environment variables and access them via process.env.FTP_USERNAME and process.env.FTP_PASSWORD, for example.
Passwords or tokens really shouldn't be hardcoded and readable.
If you have a lot of configuration values, credentials or tokens, then you can consider using dotenv (https://www.npmjs.com/package/dotenv) or something similar.
Edit
Now that we learned about the OP requirements with his comments below this answer...
It is not possible to hide passwords in any application. It will always be possible to extract them.
Consider changing the server side code so that your applications don't talk with the FTP server directly but with a proxy where credentials are not required. The proxy then talks to the FTP server and the credentials will not be exposed.
Consider using a system that provides access via tokens in addition to credentials. You could ask users to login with their personal credentials and the system could generate and send personal access tokens for the server.
if you don't want to have them on the code and you don't want users to login with their own credentials, then I can only think of either having them on a separate file that compiles the info or do a request to a server that generates session data for the app.
But people with a bit of knowledge would still have ways to get the info in both cases.
I'm creating a website for some company I work with. It includes user authentification. The database stores the hashed passwords.
At some point on a certain page, the user should be able to sign in via a popup. That requires an asynchronous request to a php file that will request the database with the password.
Which leads me to my question : should I use Javascript to hash the password before it is sent in my asynchronous request, to prevent, for example, man-in-the-middle attacks or things like that ? I don't know if the site will be using HTTPS yet.
Thanks.
Client side hashing can never replace server side hashing. A man in the middle can not only use the "encrypted" password directly as the new password, he can also strip away the JavaScript which encrypts the password. Even worse he could send a copy of the real password to another server, so you would not even recognize the change.
The only option for a website is to use an encrypted HTTPS/SSL connection. There you can send the password plaintext, SSL takes care of secure transport.
Sending hashed passwords isn't going to stop anyone sniffing your connection. The HTTP request contains the hashed pass, which is clearly readable since the request itself isn't encrypted.
If you want to be safe from this sort of stuff, use HTTPS
We are developing an application that requires serious security. Now, my problem is that client enters a password, and that password should be sent to another client in an email. The key point here is that even the server should not see the password, so the client must send the email directly to another client through the application using client-side stuff.
If you want to transfer the Data from one client to another by email you must go through a server. In this situation what I recommend is encoding the password with a key that only the clients have access to, thus making it unreadable to the server. Or having the key stored on a different server.
You will need an email server that you can install on the client.
There are several Python based email servers. FreeSMTP is easy to install and configure but is only free for 10 emails per day - but certainly easy to get going for proof of concept.
Finally you will need to talk to the email server from your client code. It is not clear from your question whether you client is Flex or JavaScript. If you are using Flex, then SMTPMailer might help. http://code.google.com/p/smtpmailer/. It might not be possible to do this with JavaScript - see Javascript IMAP and SMTP client?.
The concept doesn't seem to be a good one though. Instead can you send a non reversible hash derived from the password - then the server will never see the password - but the hash may still be useful for authentication purposes.
I'm looking for a secure way to store FTP passwords in a database that are usable only by specific users. The FTP details should be stored in a way that if the entire database is exposed that the FTP password isn't exposed. This probably should rely on the user's password to temporarily unencrypted the FTP password only when the user prompts for a FTP action. I'm looking for a solution that could implement this. Probably useful to add it concerns a web based application using javascript and php.
This is not about how to use salt, hashes, md5, sha1 etc. This is about securing FTP passwords that the server should be able to use e.g. connect to a FTP server with. This is simply not possible with hashes because those are only one way. Some symmetric password method should be used.
Example use case:
User logs in to server
User tells server to download file from his FTP details stored securely on the server
Server looks up the FTP details and removes the encryption (possibly with the users password) This question is about how you implement this step effectively
Server does whatever it has to do and then removes the unencrypted password
You could use Mcrypt: http://php.net/manual/book.mcrypt.php
Edit: While the following no longer appears to apply to the question (which now seems to want to run an FTP action on account of a user (not connected via a universal authentication mechanism), which requires a reversible scheme), I am leaving it because I think it contains valuable information.
I recommend reading Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes.
It will likely answer a number of questions, including what salt is (how to prevent rainbow attacks), why MD5 isn't an ideal solution for a password hash (it's too fast and no longer requires a "significant crypto breakthrough"), what can happen if data is compromised (why plain-text is not stored), etc. It provides valuable insights.
I really like this quote:
No, really. Use someone else’s password system. Don’t build your own.
It's so true, even if tongue-in-cheek.
It sounds like what you are looking for is an MD5 hash.
http://en.wikipedia.org/wiki/MD5
They are frequently used when storing passwords into a database, for further security you might also want to look into salting the password as well.
http://en.wikipedia.org/wiki/Salt_(cryptography)
just to know, is it possible to send password through an Ajax request safely?
I've a login box that calls an ajax request to try the login/pass and retrieve a JSON Object with errors (if any).
Should I use a form redirection instead?
[EDIT] Store the encrypted password in the database isn't the solution because the login and password send by ajax are the login / password to access the database itself (internal application).
The only way to send something that can not be intercepted by a third party is by using HTTPS instead of regular HTTP. That way everything sent between the server and the client is strongly encrypted.
For the technical hell of it, you can. If you have access to a one-way cryptographic function crypt(text,key) that supports crypt(crypt(T,A),B) == crypt(crypt(T,B),A) you can do the following:
Have a secret key for your application, KEY. Never tell anyone.
When the user registers, store crypt(password,KEY) in the database.
When the user wants to log in, send them a randomly generated key RAND
The user types the password, the form computes and sends crypt(password,RAND) through unsecure AJAX. The password never leaves the user's computer.
The server computes crypt(crypt(password,RAND),KEY) from the form response, crypt(crypt(password,KEY),RAND) from the database, and compares the two. They should be equal.
All of this is unnecessary complicated an requires a lot of effort to implement correctly and securely. Buying an SSL certificate and using HTTPS is orders of magnitude easier to achieve this level of security, and even more.
Here's what you could do:
Hash Password and store in database
On client side: hash password, then add salt (concatenate session_id string), then hash again
On server: take hashed pw from database, then add salt (concatenate session_id string), then hash again
[Edit: and then compare the hash-salt-hash generated on the server with the one sent from the client]
Intercepting your hash-salt-hash password is quite useless now, because it is only valid for that particular session...
What you're looking for is a "zero knowledge protocol". It is a way of communicating that you know a password without sending it. You would communicate between the javascript running in the user's browser, and the server.
Bonus, these protocols are generally secure even if the connection isn't encrypted. Note that it would be stupid to rely on this and not use SSL, because a man in the middle would simply replace your nice zero knowledge protocol implementation with a look-alike function that just sends the password.