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
Related
While logging on to services of Gmail, Facebook and other sites also, if on performing inspect element and checking the "Preserve Log" box, the password is clearly visible without any encryption in one of the files being sent to the server.
The same doesn't happen when logging into Yahoomail
Why exactly is this occurring? Is it some bug or some programming error? The data being sent to the server is without any encryption. Using tools like WireShark, the passwords can easily be sniffed.
Why, yes, indeed, passwords that you type into a form and then submit that form to the server are in plaintext. By necessity. Because the server needs the plaintext password to authenticate you. Hopefully the connection this plaintext is sent across is HTTPS encrypted, which means no third party can intercept the traffic and see the plaintext. Your browser happens to be able to display the plaintext for you, since, well, it's the originator of the data and a peer in the HTTPS connection.
I don't know what specifically you're doing with Yahoo, but at some point it too will have to send the password to the server in some form or another.
I have the following situation:
I have a Javascript website where the user need to enter a username and a password and then the site make a ajax call to the Webserver.
On the other site I have a Webserver running PHP which gets the parameters and checks if the username and password is right.
Now my Problem:
How to secure this process e.g: how to secure it if the website does not use https and the user submits his username and password? Is there any algorithm which can do this?
No, this is not possible.
Even if you hash or encrypt the data in the browser before sending it, the algorithm and keys would be public, and the resulting information also can be intercepted and replicated by an attacker.
If you want it to be secure, you need to 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 consider Javascript a security risk, therefore I would like to allow users of my website to login without having to have Javascript enabled.
This brings me to another problem. Without client-side-scripting I have no idea how I can hash the users password at the client side so to avoid plaintext password transmission.
How can "pure HTML+CSS" allow me to have a password hashed.
At present it seems to me the only safe option (without Javascript) would be to have a secure(encrypted) ssl/https connection and send password as plaintext?
Anyhow: Is there some way to hash the users password as to avoid to send it over the internet in plaintext.? Is this possible only using client-side-scripting?
[update]
I am aware that SSL is maybe the most close to ideal way. (as mentioned in the comments) Anyhow. It would be already an security improvement when at no time a plaintext username and plaintext password would be send via an unsafe channel. The hashes can be sniffed as well and no safty (i.e encryption) can be there. BUT at no time a sniffer will be able to get the unhased version of the username and password. => advantage would be that users will not make public their username/password combination (potentially used elsewhere).
After all it seems like there is no "scripting disabled"-way of (spice)hashing some input-field values. So I assume my question is unsolveable.
First of all, if you are using SSL, then the password is not being sent in plain text. Everything beyond the initial handshake is encrypted, and quite securely at that. Consider that this is the security that banks, the military, government all over the world rely upon daily. I'm not saying that you should trust it just because everyone else does (argument from authority) - I'm just saying that if there were a problem with it, we'll hear about it right away.
Second of all, you don't ever really gain anything by client side hashing. The basic attack you're trying to prevent is a man-in-the-middle (MITM) attack. Whether its someone eavesdropping on the connection, sniffing the password for a replay attack, or actively hijacking the session (i.e. pretending to be the server and the client to opposite ends of the connection), you can't really prevent it through additional security.
If you assume that the attacker can break through your SSL encryption, then any other token that relies on something the client software is doing or something that the server is sending along can be compromised. If its some client-side hash function, then the attacker can either learn what the function is by inspecting the webpage the server sends down or just sniff the hashed value and use it to impersonate the client when the attacker communicates with the server. If there is some secure key or token the server sends down for the client to use and respond with, the attacker can just intercept that.
I think what you're looking for is two-factor authentication.
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.