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.
Related
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
I'm currently developing an application in HTML+JS based almost entirely in ajax connections (using the jQuery.ajax() call to ease the process).
I was thinking about the best practice to make secure calls without using HTTPS (at least at this time. I can't afford paying for a certificate right now).
At this point, the only thing that concerns me is the registration and login steps. Maybe the login is a bit easier. I thought of sending the username and a timestamp, and then encrypt them using the user's password. So, by doing this, I wouldn't be sending any password (keeping as a secret like in OAuth). The server should check the user, decrypt using the password and pairing the recieved timestamp with the decrypted result. The server should keep the nonce-like number into a database (to avoid repetition attacks) and then give back to the user another unique id (encrypted with the user's password). At that point the user should start using that key to encrypt all his information (and probably another nonce) and send it to the server. Please correct me if you find any mistake or leak.
The very big problem to me is the registration. I can't encrypt with a regular password the information, because if I do that in the javascript, any could know the password. If I serve temporary generated passwords to encrypt and I send it from the server to the client, any sniffer could get it and use to decrypt the info.
I know HTTPS could save my life at this point (and maybe that's the only solution), but at this point I'm not able to use it.
Is there any other solution, or should I wait until I can use HTTPS? Bear in mind that if I could skip the wait, it would be better. Thanks mates!
Short answer: You can't do it without HTTPS
Longer answer: If you try to do it without HTTPS, you will find yourself trying to reproduce everything that HTTPS was designed to do. You could reach at some point, but it is unrealistic to believe that you will succeed in implementing even the 1% that HTTPS offers. The only benefit you will have would be an obscure security mechanism (security through obscurity), which may be OK for not critical systems, but would fail miserably in a real critical situation.
You could create your own certificate you know and then work with Ajax the same way as with regular HTTP calls. The only drawback is that the users will get a warning message.
Using an SSL Certificate is the only way really, if you encrypt it in javascript anyone can read the code and decrypt it.
http://www.startssl.com/
Generate a public/private key pair on the server, along with a randomly-generated salt.
Attach the key pair and salt to the user session object.
Send the public key and the salt to the client-side code.
Use the public key and salt to encrypt the AJAX requests.
This would not be a trivial task. You'll probably find that it's cheaper and more effective to just buy a certificate.
EDIT: This also means that all the regular HTTP traffic (HTML, images, CSS, etc) is sent in the clear. That could be a problem, since it might allow an eavesdropper to indirectly figure out what the user is doing.
I think you should have a look at :
http://assl.sullof.com/assl/
Here is the description of the project :
aSSL is a library distributed under MIT License thats implements a technology similar to SSL without HTTPS.
aSSL enables the client to negotiate a secret random 128-bit key with the server using the RSA algorithm. Once the connection has been established, the data will be sent and received using AES algorithm.
aSSL is composed of some Javascript files and a server side component. Because I have recently changed the negotiation algoritm from RC4 to RSA, only a pure Javascript (ASP) server component is currently available. I will do a porting for the main web languages (PHP, Java, Perl, Python, TKL, etc.) as soon as possible once the library has passed the beta phase.
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.
Is there any way of authenticating a homepage using JavaScript? I do know a couple of ways but they are extremly easy to "hack" because the username and passwords are stored in the script itself - as arrays.
Do you guys know any good ways of authenticating just a single subpage or two?
No, there is absolutely no way to authenticate a user using pure JavaScript.
JavaScript is executed on the client side, and thus entirely and easily manipulable.
Authentication always needs to be done on server side. JavaScript can be used to send the credentials to the server, but never to check those credentials.
Ou yeah, there is a safe solution. It's called "challenge/response technique". It works like this:
server send to client a challenge (some random string)
client attach to received chalenge a password (from user input) and make hash of this combination
server do the same (challenge + password from DB) and verify equality
if everything is OK, server logins user to site
Safety is achieved by that mean, that server send every challenge only once! If anybody capture client's response, it is not adaptable, cos server never send this challenge again.
As long as the final decision on whether or not the user gets to see some content is done on the client, it will be pretty easy to hack.
The only way that could possibly work would be if you somehow encode the content with a password, so that the desired information is simply not accessible as long as the password is not know. But even that is probably easily brute-forced and it would be quite complicated to implement.
It is certainly possible: you can encrypt the web page and use javascript to decrypt it. It rarely makes sense to do that, though.
It's not possible. Any data sent to the client in an unauthorized session should be considered public. Any sensitive data (eg: passwords) sent to the client in an unauthorized session should be considered compromised. Any data received from the client should be considered untrustworthy.
You can only trust the server.
Of course, you could write your server-side code in JavaScript using nodeJS